commit 7d039b9717d756668b603fee0c204c97fcb0e8a9 Author: Ben Hutchings Date: Wed Nov 5 20:27:50 2014 +0000 Linux 3.2.64 commit 544bd1bf08f824dc972832fba6d92b34a5a93f69 Author: Guillaume Nault Date: Wed Sep 3 14:12:55 2014 +0200 l2tp: fix race while getting PMTU on PPP pseudo-wire commit eed4d839b0cdf9d84b0a9bc63de90fd5e1e886fb upstream. Use dst_entry held by sk_dst_get() to retrieve tunnel's PMTU. The dst_mtu(__sk_dst_get(tunnel->sock)) call was racy. __sk_dst_get() could return NULL if tunnel->sock->sk_dst_cache was reset just before the call, thus making dst_mtu() dereference a NULL pointer: [ 1937.661598] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 1937.664005] IP: [] pppol2tp_connect+0x33d/0x41e [l2tp_ppp] [ 1937.664005] PGD daf0c067 PUD d9f93067 PMD 0 [ 1937.664005] Oops: 0000 [#1] SMP [ 1937.664005] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables udp_tunnel pppoe pppox ppp_generic slhc deflate ctr twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common blowfish_generic blowfish_x86_64 blowfish_common des_generic cbc xcbc rmd160 sha512_generic hmac crypto_null af_key xfrm_algo 8021q garp bridge stp llc tun atmtcp clip atm ext3 mbcache jbd iTCO_wdt coretemp kvm_intel iTCO_vendor_support kvm pcspkr evdev ehci_pci lpc_ich mfd_core i5400_edac edac_core i5k_amb shpchp button processor thermal_sys xfs crc32c_generic libcrc32c dm_mod usbhid sg hid sr_mod sd_mod cdrom crc_t10dif crct10dif_common ata_generic ahci ata_piix tg3 libahci libata uhci_hcd ptp ehci_hcd pps_core usbcore scsi_mod libphy usb_common [last unloaded: l2tp_core] [ 1937.664005] CPU: 0 PID: 10022 Comm: l2tpstress Tainted: G O 3.17.0-rc1 #1 [ 1937.664005] Hardware name: HP ProLiant DL160 G5, BIOS O12 08/22/2008 [ 1937.664005] task: ffff8800d8fda790 ti: ffff8800c43c4000 task.ti: ffff8800c43c4000 [ 1937.664005] RIP: 0010:[] [] pppol2tp_connect+0x33d/0x41e [l2tp_ppp] [ 1937.664005] RSP: 0018:ffff8800c43c7de8 EFLAGS: 00010282 [ 1937.664005] RAX: ffff8800da8a7240 RBX: ffff8800d8c64600 RCX: 000001c325a137b5 [ 1937.664005] RDX: 8c6318c6318c6320 RSI: 000000000000010c RDI: 0000000000000000 [ 1937.664005] RBP: ffff8800c43c7ea8 R08: 0000000000000000 R09: 0000000000000000 [ 1937.664005] R10: ffffffffa048e2c0 R11: ffff8800d8c64600 R12: ffff8800ca7a5000 [ 1937.664005] R13: ffff8800c439bf40 R14: 000000000000000c R15: 0000000000000009 [ 1937.664005] FS: 00007fd7f610f700(0000) GS:ffff88011a600000(0000) knlGS:0000000000000000 [ 1937.664005] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1937.664005] CR2: 0000000000000020 CR3: 00000000d9d75000 CR4: 00000000000027e0 [ 1937.664005] Stack: [ 1937.664005] ffffffffa049da80 ffff8800d8fda790 000000000000005b ffff880000000009 [ 1937.664005] ffff8800daf3f200 0000000000000003 ffff8800c43c7e48 ffffffff81109b57 [ 1937.664005] ffffffff81109b0e ffffffff8114c566 0000000000000000 0000000000000000 [ 1937.664005] Call Trace: [ 1937.664005] [] ? pppol2tp_connect+0x235/0x41e [l2tp_ppp] [ 1937.664005] [] ? might_fault+0x9e/0xa5 [ 1937.664005] [] ? might_fault+0x55/0xa5 [ 1937.664005] [] ? rcu_read_unlock+0x1c/0x26 [ 1937.664005] [] SYSC_connect+0x87/0xb1 [ 1937.664005] [] ? sysret_check+0x1b/0x56 [ 1937.664005] [] ? trace_hardirqs_on_caller+0x145/0x1a1 [ 1937.664005] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 1937.664005] [] ? spin_lock+0x9/0xb [ 1937.664005] [] SyS_connect+0x9/0xb [ 1937.664005] [] system_call_fastpath+0x16/0x1b [ 1937.664005] Code: 10 2a 84 81 e8 65 76 bd e0 65 ff 0c 25 10 bb 00 00 4d 85 ed 74 37 48 8b 85 60 ff ff ff 48 8b 80 88 01 00 00 48 8b b8 10 02 00 00 <48> 8b 47 20 ff 50 20 85 c0 74 0f 83 e8 28 89 83 10 01 00 00 89 [ 1937.664005] RIP [] pppol2tp_connect+0x33d/0x41e [l2tp_ppp] [ 1937.664005] RSP [ 1937.664005] CR2: 0000000000000020 [ 1939.559375] ---[ end trace 82d44500f28f8708 ]--- Fixes: f34c4a35d879 ("l2tp: take PMTU from tunnel UDP socket") Signed-off-by: Guillaume Nault Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 77e4d28c8f46abfe542ac3ade2c877fd7b13c150 Author: Nadav Amit Date: Tue Oct 28 00:03:43 2014 +0200 KVM: x86: Fix far-jump to non-canonical check commit 7e46dddd6f6cd5dbf3c7bd04a7e75d19475ac9f2 upstream. Commit d1442d85cc30 ("KVM: x86: Handle errors when RIP is set during far jumps") introduced a bug that caused the fix to be incomplete. Due to incorrect evaluation, far jump to segment with L bit cleared (i.e., 32-bit segment) and RIP with any of the high bits set (i.e, RIP[63:32] != 0) set may not trigger #GP. As we know, this imposes a security problem. In addition, the condition for two warnings was incorrect. Fixes: d1442d85cc30ea75f7d399474ca738e0bc96f715 Reported-by: Dan Carpenter Signed-off-by: Nadav Amit [Add #ifdef CONFIG_X86_64 to avoid complaints of undefined behavior. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Ben Hutchings commit 607530bf21828c96c2880282c844088baf6ae3c4 Author: Jens Axboe Date: Tue Sep 16 13:38:51 2014 -0600 genhd: fix leftover might_sleep() in blk_free_devt() commit 46f341ffcfb5d8530f7d1e60f3be06cce6661b62 upstream. Commit 2da78092 changed the locking from a mutex to a spinlock, so we now longer sleep in this context. But there was a leftover might_sleep() in there, which now triggers since we do the final free from an RCU callback. Get rid of it. Reported-by: Pontus Fuchs Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit 77179bb84cada16355fc832cc12dde32dd45a5f2 Author: Steven Rostedt (Red Hat) Date: Thu Oct 2 16:51:18 2014 -0400 ring-buffer: Fix infinite spin in reading buffer commit 24607f114fd14f2f37e3e0cb3d47bce96e81e848 upstream. Commit 651e22f2701b "ring-buffer: Always reset iterator to reader page" fixed one bug but in the process caused another one. The reset is to update the header page, but that fix also changed the way the cached reads were updated. The cache reads are used to test if an iterator needs to be updated or not. A ring buffer iterator, when created, disables writes to the ring buffer but does not stop other readers or consuming reads from happening. Although all readers are synchronized via a lock, they are only synchronized when in the ring buffer functions. Those functions may be called by any number of readers. The iterator continues down when its not interrupted by a consuming reader. If a consuming read occurs, the iterator starts from the beginning of the buffer. The way the iterator sees that a consuming read has happened since its last read is by checking the reader "cache". The cache holds the last counts of the read and the reader page itself. Commit 651e22f2701b changed what was saved by the cache_read when the rb_iter_reset() occurred, making the iterator never match the cache. Then if the iterator calls rb_iter_reset(), it will go into an infinite loop by checking if the cache doesn't match, doing the reset and retrying, just to see that the cache still doesn't match! Which should never happen as the reset is suppose to set the cache to the current value and there's locks that keep a consuming reader from having access to the data. Fixes: 651e22f2701b "ring-buffer: Always reset iterator to reader page" Signed-off-by: Steven Rostedt Signed-off-by: Ben Hutchings commit 7756f3a8792b7696f3e7aed47671359af8bf549e Author: Julian Anastasov Date: Thu Jul 10 09:24:01 2014 +0300 ipvs: avoid netns exit crash on ip_vs_conn_drop_conntrack commit 2627b7e15c5064ddd5e578e4efd948d48d531a3f upstream. commit 8f4e0a18682d91 ("IPVS netns exit causes crash in conntrack") added second ip_vs_conn_drop_conntrack call instead of just adding the needed check. As result, the first call still can cause crash on netns exit. Remove it. Signed-off-by: Julian Anastasov Signed-off-by: Hans Schillstrom Signed-off-by: Simon Horman Signed-off-by: Ben Hutchings commit 5b6da64a7e447eadce0d3e201c0fd6f540f2ec93 Author: Sergio Gelato Date: Wed Sep 24 08:47:24 2014 +0200 nfsd: Fix ACL null pointer deref BugLink: http://bugs.launchpad.net/bugs/1348670 Fix regression introduced in pre-3.14 kernels by cherry-picking aa07c713ecfc0522916f3cd57ac628ea6127c0ec (NFSD: Call ->set_acl with a NULL ACL structure if no entries). The affected code was removed in 3.14 by commit 4ac7249ea5a0ceef9f8269f63f33cc873c3fac61 (nfsd: use get_acl and ->set_acl). The ->set_acl methods are already able to cope with a NULL argument. Signed-off-by: Sergio Gelato [bwh: Rewrite the subject] Signed-off-by: Ben Hutchings commit 4b808fd2ef61f6d8bdaabe30b67da3f5ea9948bf Author: Jan Kara Date: Tue Nov 5 01:15:38 2013 +0100 ext2: Fix fs corruption in ext2_get_xip_mem() commit 7ba3ec5749ddb61f79f7be17b5fd7720eebc52de upstream. Commit 8e3dffc651cb "Ext2: mark inode dirty after the function dquot_free_block_nodirty is called" unveiled a bug in __ext2_get_block() called from ext2_get_xip_mem(). That function called ext2_get_block() mistakenly asking it to map 0 blocks while 1 was intended. Before the above mentioned commit things worked out fine by luck but after that commit we started returning that we allocated 0 blocks while we in fact allocated 1 block and thus allocation was looping until all blocks in the filesystem were exhausted. Fix the problem by properly asking for one block and also add assertion in ext2_get_blocks() to catch similar problems. Reported-and-tested-by: Andiry Xu Signed-off-by: Jan Kara Signed-off-by: Ben Hutchings commit 15004af9098f718266649c90be5a684bdd680b5a Author: Mikulas Patocka Date: Thu Aug 28 11:09:31 2014 -0400 dm crypt: fix access beyond the end of allocated space commit d49ec52ff6ddcda178fc2476a109cf1bd1fa19ed upstream. The DM crypt target accesses memory beyond allocated space resulting in a crash on 32 bit x86 systems. This bug is very old (it dates back to 2.6.25 commit 3a7f6c990ad04 "dm crypt: use async crypto"). However, this bug was masked by the fact that kmalloc rounds the size up to the next power of two. This bug wasn't exposed until 3.17-rc1 commit 298a9fa08a ("dm crypt: use per-bio data"). By switching to using per-bio data there was no longer any padding beyond the end of a dm-crypt allocated memory block. To minimize allocation overhead dm-crypt puts several structures into one block allocated with kmalloc. The block holds struct ablkcipher_request, cipher-specific scratch pad (crypto_ablkcipher_reqsize(any_tfm(cc))), struct dm_crypt_request and an initialization vector. The variable dmreq_start is set to offset of struct dm_crypt_request within this memory block. dm-crypt allocates the block with this size: cc->dmreq_start + sizeof(struct dm_crypt_request) + cc->iv_size. When accessing the initialization vector, dm-crypt uses the function iv_of_dmreq, which performs this calculation: ALIGN((unsigned long)(dmreq + 1), crypto_ablkcipher_alignmask(any_tfm(cc)) + 1). dm-crypt allocated "cc->iv_size" bytes beyond the end of dm_crypt_request structure. However, when dm-crypt accesses the initialization vector, it takes a pointer to the end of dm_crypt_request, aligns it, and then uses it as the initialization vector. If the end of dm_crypt_request is not aligned on a crypto_ablkcipher_alignmask(any_tfm(cc)) boundary the alignment causes the initialization vector to point beyond the allocated space. Fix this bug by calculating the variable iv_size_padding and adding it to the allocated size. Also correct the alignment of dm_crypt_request. struct dm_crypt_request is specific to dm-crypt (it isn't used by the crypto subsystem at all), so it is aligned on __alignof__(struct dm_crypt_request). Signed-off-by: Mikulas Patocka Signed-off-by: Ben Hutchings commit 9e793c5ed9204271ecc2cb7c899010e70561a452 Author: Andy Lutomirski Date: Wed Oct 8 09:02:13 2014 -0700 x86,kvm,vmx: Preserve CR4 across VM entry commit d974baa398f34393db76be45f7d4d04fbdbb4a0a upstream. CR4 isn't constant; at least the TSD and PCE bits can vary. TBH, treating CR0 and CR3 as constant scares me a bit, too, but it looks like it's correct. This adds a branch and a read from cr4 to each vm entry. Because it is extremely likely that consecutive entries into the same vcpu will have the same host cr4 value, this fixes up the vmcs instead of restoring cr4 after the fact. A subsequent patch will add a kernel-wide cr4 shadow, reducing the overhead in the common case to just two memory reads and a branch. Signed-off-by: Andy Lutomirski Acked-by: Paolo Bonzini Cc: stable@vger.kernel.org Cc: Petr Matousek Cc: Gleb Natapov Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: - Adjust context - Add struct vcpu_vmx *vmx parameter to vmx_set_constant_host_state(), done upstream in commit a547c6db4d2f ("KVM: VMX: Enable acknowledge interupt on vmexit")] Signed-off-by: Ben Hutchings commit 3a8c709ba4cf6fe86f5069c71325029d412bcf1e Author: Daniel Borkmann Date: Thu Oct 9 22:55:33 2014 +0200 net: sctp: fix remote memory pressure from excessive queueing commit 26b87c7881006311828bb0ab271a551a62dcceb4 upstream. This scenario is not limited to ASCONF, just taken as one example triggering the issue. When receiving ASCONF probes in the form of ... -------------- INIT[ASCONF; ASCONF_ACK] -------------> <----------- INIT-ACK[ASCONF; ASCONF_ACK] ------------ -------------------- COOKIE-ECHO --------------------> <-------------------- COOKIE-ACK --------------------- ---- ASCONF_a; [ASCONF_b; ...; ASCONF_n;] JUNK ------> [...] ---- ASCONF_m; [ASCONF_o; ...; ASCONF_z;] JUNK ------> ... where ASCONF_a, ASCONF_b, ..., ASCONF_z are good-formed ASCONFs and have increasing serial numbers, we process such ASCONF chunk(s) marked with !end_of_packet and !singleton, since we have not yet reached the SCTP packet end. SCTP does only do verification on a chunk by chunk basis, as an SCTP packet is nothing more than just a container of a stream of chunks which it eats up one by one. We could run into the case that we receive a packet with a malformed tail, above marked as trailing JUNK. All previous chunks are here goodformed, so the stack will eat up all previous chunks up to this point. In case JUNK does not fit into a chunk header and there are no more other chunks in the input queue, or in case JUNK contains a garbage chunk header, but the encoded chunk length would exceed the skb tail, or we came here from an entirely different scenario and the chunk has pdiscard=1 mark (without having had a flush point), it will happen, that we will excessively queue up the association's output queue (a correct final chunk may then turn it into a response flood when flushing the queue ;)): I ran a simple script with incremental ASCONF serial numbers and could see the server side consuming excessive amount of RAM [before/after: up to 2GB and more]. The issue at heart is that the chunk train basically ends with !end_of_packet and !singleton markers and since commit 2e3216cd54b1 ("sctp: Follow security requirement of responding with 1 packet") therefore preventing an output queue flush point in sctp_do_sm() -> sctp_cmd_interpreter() on the input chunk (chunk = event_arg) even though local_cork is set, but its precedence has changed since then. In the normal case, the last chunk with end_of_packet=1 would trigger the queue flush to accommodate possible outgoing bundling. In the input queue, sctp_inq_pop() seems to do the right thing in terms of discarding invalid chunks. So, above JUNK will not enter the state machine and instead be released and exit the sctp_assoc_bh_rcv() chunk processing loop. It's simply the flush point being missing at loop exit. Adding a try-flush approach on the output queue might not work as the underlying infrastructure might be long gone at this point due to the side-effect interpreter run. One possibility, albeit a bit of a kludge, would be to defer invalid chunk freeing into the state machine in order to possibly trigger packet discards and thus indirectly a queue flush on error. It would surely be better to discard chunks as in the current, perhaps better controlled environment, but going back and forth, it's simply architecturally not possible. I tried various trailing JUNK attack cases and it seems to look good now. Joint work with Vlad Yasevich. Fixes: 2e3216cd54b1 ("sctp: Follow security requirement of responding with 1 packet") Signed-off-by: Daniel Borkmann Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 9a3c6f2e051b608181aff9345481e586b2d54fc9 Author: Daniel Borkmann Date: Thu Oct 9 22:55:32 2014 +0200 net: sctp: fix panic on duplicate ASCONF chunks commit b69040d8e39f20d5215a03502a8e8b4c6ab78395 upstream. When receiving a e.g. semi-good formed connection scan in the form of ... -------------- INIT[ASCONF; ASCONF_ACK] -------------> <----------- INIT-ACK[ASCONF; ASCONF_ACK] ------------ -------------------- COOKIE-ECHO --------------------> <-------------------- COOKIE-ACK --------------------- ---------------- ASCONF_a; ASCONF_b -----------------> ... where ASCONF_a equals ASCONF_b chunk (at least both serials need to be equal), we panic an SCTP server! The problem is that good-formed ASCONF chunks that we reply with ASCONF_ACK chunks are cached per serial. Thus, when we receive a same ASCONF chunk twice (e.g. through a lost ASCONF_ACK), we do not need to process them again on the server side (that was the idea, also proposed in the RFC). Instead, we know it was cached and we just resend the cached chunk instead. So far, so good. Where things get nasty is in SCTP's side effect interpreter, that is, sctp_cmd_interpreter(): While incoming ASCONF_a (chunk = event_arg) is being marked !end_of_packet and !singleton, and we have an association context, we do not flush the outqueue the first time after processing the ASCONF_ACK singleton chunk via SCTP_CMD_REPLY. Instead, we keep it queued up, although we set local_cork to 1. Commit 2e3216cd54b1 changed the precedence, so that as long as we get bundled, incoming chunks we try possible bundling on outgoing queue as well. Before this commit, we would just flush the output queue. Now, while ASCONF_a's ASCONF_ACK sits in the corked outq, we continue to process the same ASCONF_b chunk from the packet. As we have cached the previous ASCONF_ACK, we find it, grab it and do another SCTP_CMD_REPLY command on it. So, effectively, we rip the chunk->list pointers and requeue the same ASCONF_ACK chunk another time. Since we process ASCONF_b, it's correctly marked with end_of_packet and we enforce an uncork, and thus flush, thus crashing the kernel. Fix it by testing if the ASCONF_ACK is currently pending and if that is the case, do not requeue it. When flushing the output queue we may relink the chunk for preparing an outgoing packet, but eventually unlink it when it's copied into the skb right before transmission. Joint work with Vlad Yasevich. Fixes: 2e3216cd54b1 ("sctp: Follow security requirement of responding with 1 packet") Signed-off-by: Daniel Borkmann Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit aa001b043dde50e2856fe9460bc819d2a70dc309 Author: Daniel Borkmann Date: Thu Oct 9 22:55:31 2014 +0200 net: sctp: fix skb_over_panic when receiving malformed ASCONF chunks commit 9de7922bc709eee2f609cd01d98aaedc4cf5ea74 upstream. Commit 6f4c618ddb0 ("SCTP : Add paramters validity check for ASCONF chunk") added basic verification of ASCONF chunks, however, it is still possible to remotely crash a server by sending a special crafted ASCONF chunk, even up to pre 2.6.12 kernels: skb_over_panic: text:ffffffffa01ea1c3 len:31056 put:30768 head:ffff88011bd81800 data:ffff88011bd81800 tail:0x7950 end:0x440 dev: ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:129! [...] Call Trace: [] skb_put+0x5c/0x70 [] sctp_addto_chunk+0x63/0xd0 [sctp] [] sctp_process_asconf+0x1af/0x540 [sctp] [] ? _read_unlock_bh+0x15/0x20 [] sctp_sf_do_asconf+0x168/0x240 [sctp] [] sctp_do_sm+0x71/0x1210 [sctp] [] ? fib_rules_lookup+0xad/0xf0 [] ? sctp_cmp_addr_exact+0x32/0x40 [sctp] [] sctp_assoc_bh_rcv+0xd3/0x180 [sctp] [] sctp_inq_push+0x56/0x80 [sctp] [] sctp_rcv+0x982/0xa10 [sctp] [] ? ipt_local_in_hook+0x23/0x28 [iptable_filter] [] ? nf_iterate+0x69/0xb0 [] ? ip_local_deliver_finish+0x0/0x2d0 [] ? nf_hook_slow+0x76/0x120 [] ? ip_local_deliver_finish+0x0/0x2d0 [] ip_local_deliver_finish+0xdd/0x2d0 [] ip_local_deliver+0x98/0xa0 [] ip_rcv_finish+0x12d/0x440 [] ip_rcv+0x275/0x350 [] __netif_receive_skb+0x4ab/0x750 [] netif_receive_skb+0x58/0x60 This can be triggered e.g., through a simple scripted nmap connection scan injecting the chunk after the handshake, for example, ... -------------- INIT[ASCONF; ASCONF_ACK] -------------> <----------- INIT-ACK[ASCONF; ASCONF_ACK] ------------ -------------------- COOKIE-ECHO --------------------> <-------------------- COOKIE-ACK --------------------- ------------------ ASCONF; UNKNOWN ------------------> ... where ASCONF chunk of length 280 contains 2 parameters ... 1) Add IP address parameter (param length: 16) 2) Add/del IP address parameter (param length: 255) ... followed by an UNKNOWN chunk of e.g. 4 bytes. Here, the Address Parameter in the ASCONF chunk is even missing, too. This is just an example and similarly-crafted ASCONF chunks could be used just as well. The ASCONF chunk passes through sctp_verify_asconf() as all parameters passed sanity checks, and after walking, we ended up successfully at the chunk end boundary, and thus may invoke sctp_process_asconf(). Parameter walking is done with WORD_ROUND() to take padding into account. In sctp_process_asconf()'s TLV processing, we may fail in sctp_process_asconf_param() e.g., due to removal of the IP address that is also the source address of the packet containing the ASCONF chunk, and thus we need to add all TLVs after the failure to our ASCONF response to remote via helper function sctp_add_asconf_response(), which basically invokes a sctp_addto_chunk() adding the error parameters to the given skb. When walking to the next parameter this time, we proceed with ... length = ntohs(asconf_param->param_hdr.length); asconf_param = (void *)asconf_param + length; ... instead of the WORD_ROUND()'ed length, thus resulting here in an off-by-one that leads to reading the follow-up garbage parameter length of 12336, and thus throwing an skb_over_panic for the reply when trying to sctp_addto_chunk() next time, which implicitly calls the skb_put() with that length. Fix it by using sctp_walk_params() [ which is also used in INIT parameter processing ] macro in the verification *and* in ASCONF processing: it will make sure we don't spill over, that we walk parameters WORD_ROUND()'ed. Moreover, we're being more defensive and guard against unknown parameter types and missized addresses. Joint work with Vlad Yasevich. Fixes: b896b82be4ae ("[SCTP] ADDIP: Support for processing incoming ASCONF_ACK chunks.") Signed-off-by: Daniel Borkmann Signed-off-by: Vlad Yasevich Acked-by: Neil Horman Signed-off-by: David S. Miller [bwh: Backported to 3.2: - Adjust context - sctp_sf_violation_paramlen() doesn't take a struct net * parameter] Signed-off-by: Ben Hutchings commit f8a2b85d1f2952d5caa4c8d5717603649fc57ef1 Author: Nadav Amit Date: Thu Sep 18 22:39:39 2014 +0300 KVM: x86: Handle errors when RIP is set during far jumps commit d1442d85cc30ea75f7d399474ca738e0bc96f715 upstream. Far jmp/call/ret may fault while loading a new RIP. Currently KVM does not handle this case, and may result in failed vm-entry once the assignment is done. The tricky part of doing so is that loading the new CS affects the VMCS/VMCB state, so if we fail during loading the new RIP, we are left in unconsistent state. Therefore, this patch saves on 64-bit the old CS descriptor and restores it if loading RIP failed. This fixes CVE-2014-3647. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: - Adjust context - __load_segment_descriptor() does not take an in_task_switch parameter] Signed-off-by: Ben Hutchings commit 11c0bdb62a2d118fbb38b695d4b3ca2cf3d68344 Author: Paolo Bonzini Date: Thu May 15 17:56:57 2014 +0200 KVM: x86: use new CS.RPL as CPL during task switch commit 2356aaeb2f58f491679dc0c38bc3f6dbe54e7ded upstream. During task switch, all of CS.DPL, CS.RPL, SS.DPL must match (in addition to all the other requirements) and will be the new CPL. So far this worked by carefully setting the CS selector and flag before doing the task switch; setting CS.selector will already change the CPL. However, this will not work once we get the CPL from SS.DPL, because then you will have to set the full segment descriptor cache to change the CPL. ctxt->ops->cpl(ctxt) will then return the old CPL during the task switch, and the check that SS.DPL == CPL will fail. Temporarily assume that the CPL comes from CS.RPL during task switch to a protected-mode task. This is the same approach used in QEMU's emulation code, which (until version 2.0) manually tracks the CPL. Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: - Adjust context - load_state_from_tss32() does not support VM86 mode] Signed-off-by: Ben Hutchings commit 71ca9dc31fd6cd39ade2b3b6f1fa8fe4f2a915fa Author: Nadav Amit Date: Thu Sep 18 22:39:38 2014 +0300 KVM: x86: Emulator fixes for eip canonical checks on near branches commit 234f3ce485d54017f15cf5e0699cff4100121601 upstream. Before changing rip (during jmp, call, ret, etc.) the target should be asserted to be canonical one, as real CPUs do. During sysret, both target rsp and rip should be canonical. If any of these values is noncanonical, a #GP exception should occur. The exception to this rule are syscall and sysenter instructions in which the assigned rip is checked during the assignment to the relevant MSRs. This patch fixes the emulator to behave as real CPUs do for near branches. Far branches are handled by the next patch. This fixes CVE-2014-3647. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: - Adjust context - Use ctxt->regs[] instead of reg_read(), reg_write(), reg_rmw()] Signed-off-by: Ben Hutchings commit ea8064a24d587a95e3018f4aa5e218902a6d1734 Author: Nadav Amit Date: Thu Sep 18 22:39:37 2014 +0300 KVM: x86: Fix wrong masking on relative jump/call commit 05c83ec9b73c8124555b706f6af777b10adf0862 upstream. Relative jumps and calls do the masking according to the operand size, and not according to the address size as the KVM emulator does today. This patch fixes KVM behavior. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Ben Hutchings commit befadafe2f63f847f30aa73abb290c07c2e70499 Author: Takuya Yoshikawa Date: Tue Nov 22 15:18:35 2011 +0900 KVM: x86 emulator: Use opcode::execute for CALL commit d4ddafcdf2201326ec9717172767cfad0ede1472 upstream. CALL: E8 Signed-off-by: Takuya Yoshikawa Signed-off-by: Marcelo Tosatti [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 3f09b1f1033b9a6350b72649c6abdafdf81e5c2d Author: Petr Matousek Date: Tue Sep 23 20:22:30 2014 +0200 kvm: vmx: handle invvpid vm exit gracefully commit a642fc305053cc1c6e47e4f4df327895747ab485 upstream. On systems with invvpid instruction support (corresponding bit in IA32_VMX_EPT_VPID_CAP MSR is set) guest invocation of invvpid causes vm exit, which is currently not handled and results in propagation of unknown exit to userspace. Fix this by installing an invvpid vm exit handler. This is CVE-2014-3646. Signed-off-by: Petr Matousek Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: - Adjust filename - Drop inapplicable change to exit reason string array] Signed-off-by: Ben Hutchings commit 02a988e6e4511b1f6d83525710a12db9c5a45149 Author: Nadav Har'El Date: Mon Aug 5 11:07:17 2013 +0300 nEPT: Nested INVEPT commit bfd0a56b90005f8c8a004baf407ad90045c2b11e upstream. If we let L1 use EPT, we should probably also support the INVEPT instruction. In our current nested EPT implementation, when L1 changes its EPT table for L2 (i.e., EPT12), L0 modifies the shadow EPT table (EPT02), and in the course of this modification already calls INVEPT. But if last level of shadow page is unsync not all L1's changes to EPT12 are intercepted, which means roots need to be synced when L1 calls INVEPT. Global INVEPT should not be different since roots are synced by kvm_mmu_load() each time EPTP02 changes. Reviewed-by: Xiao Guangrong Signed-off-by: Nadav Har'El Signed-off-by: Jun Nakajima Signed-off-by: Xinhao Xu Signed-off-by: Yang Zhang Signed-off-by: Gleb Natapov Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: - Adjust context, filename - Simplify handle_invept() as recommended by Paolo - nEPT is not supported so we always raise #UD] Signed-off-by: Ben Hutchings commit 30a340f59414f02434e8b7a880241b2bd657cb7b Author: Andy Honig Date: Wed Aug 27 14:42:54 2014 -0700 KVM: x86: Improve thread safety in pit commit 2febc839133280d5a5e8e1179c94ea674489dae2 upstream. There's a race condition in the PIT emulation code in KVM. In __kvm_migrate_pit_timer the pit_timer object is accessed without synchronization. If the race condition occurs at the wrong time this can crash the host kernel. This fixes CVE-2014-3611. Signed-off-by: Andrew Honig Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 76715b56c6fcdafae8d47d4fcfe8c940e76f0553 Author: Nadav Amit Date: Tue Sep 16 03:24:05 2014 +0300 KVM: x86: Check non-canonical addresses upon WRMSR commit 854e8bb1aa06c578c2c9145fa6bfe3680ef63b23 upstream. Upon WRMSR, the CPU should inject #GP if a non-canonical value (address) is written to certain MSRs. The behavior is "almost" identical for AMD and Intel (ignoring MSRs that are not implemented in either architecture since they would anyhow #GP). However, IA32_SYSENTER_ESP and IA32_SYSENTER_EIP cause #GP if non-canonical address is written on Intel but not on AMD (which ignores the top 32-bits). Accordingly, this patch injects a #GP on the MSRs which behave identically on Intel and AMD. To eliminate the differences between the architecutres, the value which is written to IA32_SYSENTER_ESP and IA32_SYSENTER_EIP is turned to canonical value before writing instead of injecting a #GP. Some references from Intel and AMD manuals: According to Intel SDM description of WRMSR instruction #GP is expected on WRMSR "If the source register contains a non-canonical address and ECX specifies one of the following MSRs: IA32_DS_AREA, IA32_FS_BASE, IA32_GS_BASE, IA32_KERNEL_GS_BASE, IA32_LSTAR, IA32_SYSENTER_EIP, IA32_SYSENTER_ESP." According to AMD manual instruction manual: LSTAR/CSTAR (SYSCALL): "The WRMSR instruction loads the target RIP into the LSTAR and CSTAR registers. If an RIP written by WRMSR is not in canonical form, a general-protection exception (#GP) occurs." IA32_GS_BASE and IA32_FS_BASE (WRFSBASE/WRGSBASE): "The address written to the base field must be in canonical form or a #GP fault will occur." IA32_KERNEL_GS_BASE (SWAPGS): "The address stored in the KernelGSbase MSR must be in canonical form." This patch fixes CVE-2014-3610. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: - The various set_msr() functions all separate msr_index and data parameters] Signed-off-by: Ben Hutchings commit 8db33010af3020af7f4904b2dfffc9841ffc42e4 Author: Hannes Frederic Sowa Date: Fri Feb 21 02:55:35 2014 +0100 ipv6: reuse ip6_frag_id from ip6_ufo_append_data commit 916e4cf46d0204806c062c8c6c4d1f633852c5b6 upstream. Currently we generate a new fragmentation id on UFO segmentation. It is pretty hairy to identify the correct net namespace and dst there. Especially tunnels use IFF_XMIT_DST_RELEASE and thus have no skb_dst available at all. This causes unreliable or very predictable ipv6 fragmentation id generation while segmentation. Luckily we already have pregenerated the ip6_frag_id in ip6_ufo_append_data and can use it here. Signed-off-by: Hannes Frederic Sowa Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust filename, indentation] Signed-off-by: Ben Hutchings commit 4c84431245882b69537e78fea5f1686c35ddd9f9 Author: Theodore Ts'o Date: Sat Aug 23 17:47:28 2014 -0400 ext4: fix BUG_ON in mb_free_blocks() commit c99d1e6e83b06744c75d9f5e491ed495a7086b7b upstream. If we suffer a block allocation failure (for example due to a memory allocation failure), it's possible that we will call ext4_discard_allocated_blocks() before we've actually allocated any blocks. In that case, fe_len and fe_start in ac->ac_f_ex will still be zero, and this will result in mb_free_blocks(inode, e4b, 0, 0) triggering the BUG_ON on mb_free_blocks(): BUG_ON(last >= (sb->s_blocksize << 3)); Fix this by bailing out of ext4_discard_allocated_blocks() if fs_len is zero. Also fix a missing ext4_mb_unload_buddy() call in ext4_discard_allocated_blocks(). Google-Bug-Id: 16844242 Fixes: 86f0afd463215fc3e58020493482faa4ac3a4d69 Signed-off-by: Theodore Ts'o [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit a0a8667a54a43250f962bf778c031c50c31e9142 Author: chenweilong Date: Wed Aug 6 16:18:17 2014 +0800 ipv6: reallocate addrconf router for ipv6 address when lo device up It fix the bug 67951 on bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=67951 The patch can't be applied directly, as it' used the function introduced by "commit 94e187c0" ip6_rt_put(), that patch can't be applied directly either. ==================== From: Gao feng commit 33d99113b1102c2d2f8603b9ba72d89d915c13f5 upstream. This commit don't have a stable tag, but it fix the bug no reply after loopback down-up.It's very worthy to be applied to stable 3.4 kernels. The bug is 67951 on bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=67951 CC: Sabrina Dubroca CC: Hannes Frederic Sowa Reported-by: Weilong Chen Signed-off-by: Weilong Chen Signed-off-by: Gao feng Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller [weilong: s/ip6_rt_put/dst_release] Signed-off-by: Chen Weilong Signed-off-by: Ben Hutchings commit 4715883ba814db9635baf74e378580bd27a534bd Author: Marcelo Ricardo Leitner Date: Mon Oct 13 14:03:30 2014 -0300 ipv4: disable bh while doing route gc Further tests revealed that after moving the garbage collector to a work queue and protecting it with a spinlock may leave the system prone to soft lockups if bottom half gets very busy. It was reproced with a set of firewall rules that REJECTed packets. If the NIC bottom half handler ends up running on the same CPU that is running the garbage collector on a very large cache, the garbage collector will not be able to do its job due to the amount of work needed for handling the REJECTs and also won't reschedule. The fix is to disable bottom half during the garbage collecting, as it already was in the first place (most calls to it came from softirqs). Signed-off-by: Marcelo Ricardo Leitner Acked-by: Hannes Frederic Sowa Acked-by: David S. Miller Signed-off-by: Ben Hutchings commit ad5ca98f54c3b6604a7bb72059973a85deb0b779 Author: Marcelo Ricardo Leitner Date: Thu Aug 14 16:44:53 2014 -0300 ipv4: avoid parallel route cache gc executions When rt_intern_hash() has to deal with neighbour cache overflowing, it triggers the route cache garbage collector in an attempt to free some references on neighbour entries. Such call cannot be done async but should also not run in parallel with an already-running one, so that they don't collapse fighting over the hash lock entries. This patch thus blocks parallel executions with spinlocks: - A call from worker and from rt_intern_hash() are not the same, and cannot be merged, thus they will wait each other on rt_gc_lock. - Calls to gc from rt_intern_hash() may happen in parallel but we must wait for it to finish in order to try again. This dedup and synchrinozation is then performed by the locking just before calling __do_rt_garbage_collect(). Signed-off-by: Marcelo Ricardo Leitner Acked-by: Hannes Frederic Sowa Signed-off-by: Ben Hutchings commit 6c383b3a565dbf07cf6665e5da535f8668479453 Author: Marcelo Ricardo Leitner Date: Thu Aug 14 16:44:52 2014 -0300 ipv4: move route garbage collector to work queue Currently the route garbage collector gets called by dst_alloc() if it have more entries than the threshold. But it's an expensive call, that don't really need to be done by then. Another issue with current way is that it allows running the garbage collector with the same start parameters on multiple CPUs at once, which is not optimal. A system may even soft lockup if the cache is big enough as the garbage collectors will be fighting over the hash lock entries. This patch thus moves the garbage collector to run asynchronously on a work queue, much similar to how rt_expire_check runs. There is one condition left that allows multiple executions, which is handled by the next patch. Signed-off-by: Marcelo Ricardo Leitner Acked-by: Hannes Frederic Sowa Signed-off-by: Ben Hutchings commit d521f4ba086d707a6e861d46dff2b26db4f549b5 Author: Yoichi Yuasa Date: Wed Oct 2 15:03:03 2013 +0900 MIPS: Fix forgotten preempt_enable() when CPU has inclusive pcaches commit 5596b0b245fb9d2cefb5023b11061050351c1398 upstream. [ 1.904000] BUG: scheduling while atomic: swapper/1/0x00000002 [ 1.908000] Modules linked in: [ 1.916000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc2-lemote-los.git-5318619-dirty #1 [ 1.920000] Stack : 0000000031aac000 ffffffff810d0000 0000000000000052 ffffffff802730a4 0000000000000000 0000000000000001 ffffffff810cdf90 ffffffff810d0000 ffffffff8068b968 ffffffff806f5537 ffffffff810cdf90 980000009f0782e8 0000000000000001 ffffffff80720000 ffffffff806b0000 980000009f078000 980000009f290000 ffffffff805f312c 980000009f05b5d8 ffffffff80233518 980000009f05b5e8 ffffffff80274b7c 980000009f078000 ffffffff8068b968 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 980000009f05b520 0000000000000000 ffffffff805f2f6c 0000000000000000 ffffffff80700000 ffffffff80700000 ffffffff806fc758 ffffffff80700000 ffffffff8020be98 ffffffff806fceb0 ffffffff805f2f6c ... [ 2.028000] Call Trace: [ 2.032000] [] show_stack+0x80/0x98 [ 2.036000] [] __schedule_bug+0x44/0x6c [ 2.040000] [] __schedule+0x518/0x5b0 [ 2.044000] [] schedule_timeout+0x128/0x1f0 [ 2.048000] [] msleep+0x3c/0x60 [ 2.052000] [] do_probe+0x238/0x3a8 [ 2.056000] [] ide_probe_port+0x340/0x7e8 [ 2.060000] [] ide_host_register+0x2d0/0x7a8 [ 2.064000] [] ide_pci_init_two+0x4e4/0x790 [ 2.068000] [] amd74xx_probe+0x148/0x2c8 [ 2.072000] [] pci_device_probe+0xc4/0x130 [ 2.076000] [] driver_probe_device+0x98/0x270 [ 2.080000] [] __driver_attach+0xe0/0xe8 [ 2.084000] [] bus_for_each_dev+0x78/0xe0 [ 2.088000] [] bus_add_driver+0x230/0x310 [ 2.092000] [] driver_register+0x84/0x158 [ 2.096000] [] do_one_initcall+0x104/0x160 Signed-off-by: Yoichi Yuasa Reported-by: Aaro Koskinen Tested-by: Aaro Koskinen Cc: linux-mips@linux-mips.org Cc: Linux Kernel Mailing List Patchwork: https://patchwork.linux-mips.org/patch/5941/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit ff872daa0999be34260b8462802a73d855c4a814 Author: Josh Triplett Date: Fri Oct 3 16:00:54 2014 -0700 init/Kconfig: Hide printk log config if CONFIG_PRINTK=n commit 361e9dfbaae84b0b246ed18d1ab7c82a1a41b53e upstream. The buffers sized by CONFIG_LOG_BUF_SHIFT and CONFIG_LOG_CPU_MAX_BUF_SHIFT do not exist if CONFIG_PRINTK=n, so don't ask about their size at all. Signed-off-by: Josh Triplett Acked-by: Randy Dunlap [bwh: Backported to 3.2: drop change to CONFIG_LOG_CPU_MAX_BUF_SHIFT] Signed-off-by: Ben Hutchings commit 96cb09b889f547e49e443966aff537adf6630707 Author: Peter Zijlstra Date: Thu Oct 2 16:17:02 2014 -0700 perf: fix perf bug in fork() commit 6c72e3501d0d62fc064d3680e5234f3463ec5a86 upstream. Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by calling perf_event_free_task() when failing sched_fork() we will not yet have done the memset() on ->perf_event_ctxp[] and will therefore try and 'free' the inherited contexts, which are still in use by the parent process. This is bad.. Suggested-by: Oleg Nesterov Reported-by: Oleg Nesterov Reported-by: Sylvain 'ythier' Hitier Signed-off-by: Peter Zijlstra (Intel) Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit b47191f7d729d2fabd29fbbf3d57158133d4e0ef Author: Mel Gorman Date: Thu Oct 2 19:47:41 2014 +0100 mm: migrate: Close race between migration completion and mprotect commit d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 upstream. A migration entry is marked as write if pte_write was true at the time the entry was created. The VMA protections are not double checked when migration entries are being removed as mprotect marks write-migration-entries as read. It means that potentially we take a spurious fault to mark PTEs write again but it's straight-forward. However, there is a race between write migrations being marked read and migrations finishing. This potentially allows a PTE to be write that should have been read. Close this race by double checking the VMA permissions using maybe_mkwrite when migration completes. [torvalds@linux-foundation.org: use maybe_mkwrite] Signed-off-by: Mel Gorman Acked-by: Rik van Riel Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 6bf3b2e3ac32809477278d73c9e7a57d7ba82090 Author: Miklos Szeredi Date: Wed Sep 24 17:56:17 2014 +0200 shmem: fix nlink for rename overwrite directory commit b928095b0a7cff7fb9fcf4c706348ceb8ab2c295 upstream. If overwriting an empty directory with rename, then need to drop the extra nlink. Test prog: #include #include #include #include int main(void) { const char *test_dir1 = "test-dir1"; const char *test_dir2 = "test-dir2"; int res; int fd; struct stat statbuf; res = mkdir(test_dir1, 0777); if (res == -1) err(1, "mkdir(\"%s\")", test_dir1); res = mkdir(test_dir2, 0777); if (res == -1) err(1, "mkdir(\"%s\")", test_dir2); fd = open(test_dir2, O_RDONLY); if (fd == -1) err(1, "open(\"%s\")", test_dir2); res = rename(test_dir1, test_dir2); if (res == -1) err(1, "rename(\"%s\", \"%s\")", test_dir1, test_dir2); res = fstat(fd, &statbuf); if (res == -1) err(1, "fstat(%i)", fd); if (statbuf.st_nlink != 0) { fprintf(stderr, "nlink is %lu, should be 0\n", statbuf.st_nlink); return 1; } return 0; } Signed-off-by: Miklos Szeredi Signed-off-by: Al Viro Signed-off-by: Ben Hutchings commit 40d31c4997351e1c80e95eb961366c8842ab3fc1 Author: Joseph Qi Date: Thu Sep 25 16:05:16 2014 -0700 ocfs2/dlm: do not get resource spinlock if lockres is new commit 5760a97c7143c208fa3a8f8cad0ed7dd672ebd28 upstream. There is a deadlock case which reported by Guozhonghua: https://oss.oracle.com/pipermail/ocfs2-devel/2014-September/010079.html This case is caused by &res->spinlock and &dlm->master_lock misordering in different threads. It was introduced by commit 8d400b81cc83 ("ocfs2/dlm: Clean up refmap helpers"). Since lockres is new, it doesn't not require the &res->spinlock. So remove it. Fixes: 8d400b81cc83 ("ocfs2/dlm: Clean up refmap helpers") Signed-off-by: Joseph Qi Reviewed-by: joyce.xue Reported-by: Guozhonghua Cc: Joel Becker Cc: Mark Fasheh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit a428c0e1d7781192fe806246f29b4dbeaa2a7ce1 Author: Andreas Rohner Date: Thu Sep 25 16:05:14 2014 -0700 nilfs2: fix data loss with mmap() commit 56d7acc792c0d98f38f22058671ee715ff197023 upstream. This bug leads to reproducible silent data loss, despite the use of msync(), sync() and a clean unmount of the file system. It is easily reproducible with the following script: ----------------[BEGIN SCRIPT]-------------------- mkfs.nilfs2 -f /dev/sdb mount /dev/sdb /mnt dd if=/dev/zero bs=1M count=30 of=/mnt/testfile umount /mnt mount /dev/sdb /mnt CHECKSUM_BEFORE="$(md5sum /mnt/testfile)" /root/mmaptest/mmaptest /mnt/testfile 30 10 5 sync CHECKSUM_AFTER="$(md5sum /mnt/testfile)" umount /mnt mount /dev/sdb /mnt CHECKSUM_AFTER_REMOUNT="$(md5sum /mnt/testfile)" umount /mnt echo "BEFORE MMAP:\t$CHECKSUM_BEFORE" echo "AFTER MMAP:\t$CHECKSUM_AFTER" echo "AFTER REMOUNT:\t$CHECKSUM_AFTER_REMOUNT" ----------------[END SCRIPT]-------------------- The mmaptest tool looks something like this (very simplified, with error checking removed): ----------------[BEGIN mmaptest]-------------------- data = mmap(NULL, file_size - file_offset, PROT_READ | PROT_WRITE, MAP_SHARED, fd, file_offset); for (i = 0; i < write_count; ++i) { memcpy(data + i * 4096, buf, sizeof(buf)); msync(data, file_size - file_offset, MS_SYNC)) } ----------------[END mmaptest]-------------------- The output of the script looks something like this: BEFORE MMAP: 281ed1d5ae50e8419f9b978aab16de83 /mnt/testfile AFTER MMAP: 6604a1c31f10780331a6850371b3a313 /mnt/testfile AFTER REMOUNT: 281ed1d5ae50e8419f9b978aab16de83 /mnt/testfile So it is clear, that the changes done using mmap() do not survive a remount. This can be reproduced a 100% of the time. The problem was introduced in commit 136e8770cd5d ("nilfs2: fix issue of nilfs_set_page_dirty() for page at EOF boundary"). If the page was read with mpage_readpage() or mpage_readpages() for example, then it has no buffers attached to it. In that case page_has_buffers(page) in nilfs_set_page_dirty() will be false. Therefore nilfs_set_file_dirty() is never called and the pages are never collected and never written to disk. This patch fixes the problem by also calling nilfs_set_file_dirty() if the page has no buffers attached to it. [akpm@linux-foundation.org: s/PAGE_SHIFT/PAGE_CACHE_SHIFT/] Signed-off-by: Andreas Rohner Tested-by: Andreas Rohner Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit bbc3708af2adfb001b3df0e9e7479d10082772c2 Author: Markos Chandras Date: Tue Sep 16 15:55:12 2014 +0100 MIPS: mcount: Adjust stack pointer for static trace in MIPS32 commit 8a574cfa2652545eb95595d38ac2a0bb501af0ae upstream. Every mcount() call in the MIPS 32-bit kernel is done as follows: [...] move at, ra jal _mcount addiu sp, sp, -8 [...] but upon returning from the mcount() function, the stack pointer is not adjusted properly. This is explained in details in 58b69401c797 (MIPS: Function tracer: Fix broken function tracing). Commit ad8c396936e3 ("MIPS: Unbreak function tracer for 64-bit kernel.) fixed the stack manipulation for 64-bit but it didn't fix it completely for MIPS32. Signed-off-by: Markos Chandras Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7792/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit edeb8f82dff6d09343e0ec195edae6ed19d6423e Author: Robin Murphy Date: Thu Sep 25 11:56:19 2014 +0100 ARM: 8165/1: alignment: don't break misaligned NEON load/store commit 5ca918e5e3f9df4634077c06585c42bc6a8d699a upstream. The alignment fixup incorrectly decodes faulting ARM VLDn/VSTn instructions (where the optional alignment hint is given but incorrect) as LDR/STR, leading to register corruption. Detect these and correctly treat them as unhandled, so that userspace gets the fault it expects. Reported-by: Simon Hosie Signed-off-by: Robin Murphy Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit fdb7a04767162bc25bfa1dd31f9852b671a81f37 Author: Wanpeng Li Date: Wed Sep 24 16:38:05 2014 +0800 sched: Fix unreleased llc_shared_mask bit during CPU hotplug commit 03bd4e1f7265548832a76e7919a81f3137c44fd1 upstream. The following bug can be triggered by hot adding and removing a large number of xen domain0's vcpus repeatedly: BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [..] find_busiest_group PGD 5a9d5067 PUD 13067 PMD 0 Oops: 0000 [#3] SMP [...] Call Trace: load_balance ? _raw_spin_unlock_irqrestore idle_balance __schedule schedule schedule_timeout ? lock_timer_base schedule_timeout_uninterruptible msleep lock_device_hotplug_sysfs online_store dev_attr_store sysfs_write_file vfs_write SyS_write system_call_fastpath Last level cache shared mask is built during CPU up and the build_sched_domain() routine takes advantage of it to setup the sched domain CPU topology. However, llc_shared_mask is not released during CPU disable, which leads to an invalid sched domainCPU topology. This patch fix it by releasing the llc_shared_mask correctly during CPU disable. Yasuaki also reported that this can happen on real hardware: https://lkml.org/lkml/2014/7/22/1018 His case is here: == Here is an example on my system. My system has 4 sockets and each socket has 15 cores and HT is enabled. In this case, each core of sockes is numbered as follows: | CPU# Socket#0 | 0-14 , 60-74 Socket#1 | 15-29, 75-89 Socket#2 | 30-44, 90-104 Socket#3 | 45-59, 105-119 Then llc_shared_mask of CPU#30 has 0x3fff80000001fffc0000000. It means that last level cache of Socket#2 is shared with CPU#30-44 and 90-104. When hot-removing socket#2 and #3, each core of sockets is numbered as follows: | CPU# Socket#0 | 0-14 , 60-74 Socket#1 | 15-29, 75-89 But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30 remains having 0x3fff80000001fffc0000000. After that, when hot-adding socket#2 and #3, each core of sockets is numbered as follows: | CPU# Socket#0 | 0-14 , 60-74 Socket#1 | 15-29, 75-89 Socket#2 | 30-59 Socket#3 | 90-119 Then llc_shared_mask of CPU#30 becomes 0x3fff8000fffffffc0000000. It means that last level cache of Socket#2 is shared with CPU#30-59 and 90-104. So the mask has the wrong value. Signed-off-by: Wanpeng Li Tested-by: Linn Crosetto Reviewed-by: Borislav Petkov Reviewed-by: Toshi Kani Reviewed-by: Yasuaki Ishimatsu Cc: David Rientjes Cc: Prarit Bhargava Cc: Steven Rostedt Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1411547885-48165-1-git-send-email-wanpeng.li@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit cfda98930d53d1b6090c263b80c6a3e5cc2f2fe1 Author: John David Anglin Date: Mon Sep 22 20:54:50 2014 -0400 parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds commit d26a7730b5874a5fa6779c62f4ad7c5065a94723 upstream. In spite of what the GCC manual says, the -mfast-indirect-calls has never been supported in the 64-bit parisc compiler. Indirect calls have always been done using function descriptors irrespective of the -mfast-indirect-calls option. Recently, it was noticed that a function descriptor was always requested when the -mfast-indirect-calls option was specified. This caused problems when the option was used in application code and doesn't make any sense because the whole point of the option is to avoid using a function descriptor for indirect calls. Fixing this broke 64-bit kernel builds. I will fix GCC but for now we need the attached change. This results in the same kernel code as before. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Ben Hutchings commit 918b21603271ee284f25329580b06164b24b7805 Author: Anton Altaparmakov Date: Mon Sep 22 01:53:03 2014 +0100 Fix nasty 32-bit overflow bug in buffer i/o code. commit f2d5a94436cc7cc0221b9a81bba2276a25187dd3 upstream. On 32-bit architectures, the legacy buffer_head functions are not always handling the sector number with the proper 64-bit types, and will thus fail on 4TB+ disks. Any code that uses __getblk() (and thus bread(), breadahead(), sb_bread(), sb_breadahead(), sb_getblk()), and calls it using a 64-bit block on a 32-bit arch (where "long" is 32-bit) causes an inifinite loop in __getblk_slow() with an infinite stream of errors logged to dmesg like this: __find_get_block_slow() failed. block=6740375944, b_blocknr=2445408648 b_state=0x00000020, b_size=512 device sda1 blocksize: 512 Note how in hex block is 0x191C1F988 and b_blocknr is 0x91C1F988 i.e. the top 32-bits are missing (in this case the 0x1 at the top). This is because grow_dev_page() is broken and has a 32-bit overflow due to shifting the page index value (a pgoff_t - which is just 32 bits on 32-bit architectures) left-shifted as the block number. But the top bits to get lost as the pgoff_t is not type cast to sector_t / 64-bit before the shift. This patch fixes this issue by type casting "index" to sector_t before doing the left shift. Note this is not a theoretical bug but has been seen in the field on a 4TiB hard drive with logical sector size 512 bytes. This patch has been verified to fix the infinite loop problem on 3.17-rc5 kernel using a 4TB disk image mounted using "-o loop". Without this patch doing a "find /nt" where /nt is an NTFS volume causes the inifinite loop 100% reproducibly whilst with the patch it works fine as expected. Signed-off-by: Anton Altaparmakov Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 53412c3f7c9fd3cac2a33195dad87fdc1bc25103 Author: Clemens Ladisch Date: Sun Sep 21 22:50:57 2014 +0200 ALSA: pcm: fix fifo_size frame calculation commit a9960e6a293e6fc3ed414643bb4e4106272e4d0a upstream. The calculated frame size was wrong because snd_pcm_format_physical_width() actually returns the number of bits, not bytes. Use snd_pcm_format_size() instead, which not only returns bytes, but also simplifies the calculation. Fixes: 8bea869c5e56 ("ALSA: PCM midlevel: improve fifo_size handling") Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 51562cd4de104521223f8e4e9cbe04bef401a79f Author: David Dueck Date: Wed Sep 17 14:26:48 2014 +0200 can: at91_can: add missing prepare and unprepare of the clock commit e77980e50bc2850599d4d9c0192b67a9ffd6daac upstream. In order to make the driver work with the common clock framework, this patch converts the clk_enable()/clk_disable() to clk_prepare_enable()/clk_disable_unprepare(). While there, add the missing error handling. Signed-off-by: David Dueck Signed-off-by: Anthony Harivel Acked-by: Boris Brezillon Signed-off-by: Marc Kleine-Budde Signed-off-by: Ben Hutchings commit 3158bdb265224ef34e7248fd802df13e36b5f3c3 Author: Marc Kleine-Budde Date: Tue Sep 16 15:31:27 2014 +0200 can: flexcan: put TX mailbox into TX_INACTIVE mode after tx-complete commit de5944883ebbedbf5adc8497659772f5da7b7d72 upstream. After sending a RTR frame the TX mailbox becomes a RX_EMPTY mailbox. To avoid side effects when the RX-FIFO is full, this patch puts the TX mailbox into TX_INACTIVE mode in the transmission complete interrupt handler. This, of course, leaves a race window between the actual completion of the transmission and the handling of tx-complete interrupt. However this is the best we can do without busy polling the tx complete interrupt. Signed-off-by: Marc Kleine-Budde [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 7056cbe8003b8a4373bde8ec97e7178404cd0712 Author: David Jander Date: Wed Sep 3 16:47:22 2014 +0200 can: flexcan: implement workaround for errata ERR005829 commit 25e924450fcb23c11c07c95ea8964dd9f174652e upstream. This patch implements the workaround mentioned in ERR005829: ERR005829: FlexCAN: FlexCAN does not transmit a message that is enabled to be transmitted in a specific moment during the arbitration process. Workaround: The workaround consists of two extra steps after setting up a message for transmission: Step 8: Reserve the first valid mailbox as an inactive mailbox (CODE=0b1000). If RX FIFO is disabled, this mailbox must be message buffer 0. Otherwise, the first valid mailbox can be found using the "RX FIFO filters" table in the FlexCAN chapter of the chip reference manual. Step 9: Write twice INACTIVE code (0b1000) into the first valid mailbox. Signed-off-by: David Jander Signed-off-by: Marc Kleine-Budde Signed-off-by: Ben Hutchings commit d306d951e2fa1f847f043a9825d2e76d9b192929 Author: David Jander Date: Wed Aug 27 11:58:05 2014 +0200 can: flexcan: correctly initialize mailboxes commit fc05b884a31dbf259cc73cc856e634ec3acbebb6 upstream. Apparently mailboxes may contain random data at startup, causing some of them being prepared for message reception. This causes overruns being missed or even confusing the IRQ check for trasmitted messages, increasing the transmit counter instead of the error counter. This patch initializes all mailboxes after the FIFO as RX_INACTIVE. Signed-off-by: David Jander Signed-off-by: Marc Kleine-Budde Signed-off-by: Ben Hutchings commit 1b184fd1fe3f1e0e4e76d8e85a77dd5a425b289e Author: Marc Kleine-Budde Date: Tue Sep 16 12:39:28 2014 +0200 can: flexcan: mark TX mailbox as TX_INACTIVE commit c32fe4ad3e4861b2bfa1f44114c564935a123dda upstream. This patch fixes the initialization of the TX mailbox. It is now correctly initialized as TX_INACTIVE not RX_EMPTY. Signed-off-by: Marc Kleine-Budde Signed-off-by: Ben Hutchings commit a93db944b6250d4345ed30095001f8bee5ecaed7 Author: Johannes Berg Date: Wed Jul 30 14:55:26 2014 +0200 nl80211: clear skb cb before passing to netlink commit bd8c78e78d5011d8111bc2533ee73b13a3bd6c42 upstream. In testmode and vendor command reply/event SKBs we use the skb cb data to store nl80211 parameters between allocation and sending. This causes the code for CONFIG_NETLINK_MMAP to get confused, because it takes ownership of the skb cb data when the SKB is handed off to netlink, and it doesn't explicitly clear it. Clear the skb cb explicitly when we're done and before it gets passed to netlink to avoid this issue. Reported-by: Assaf Azulay Reported-by: David Spinadel Signed-off-by: Johannes Berg [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit b2d0a271e3785900eaef4d02d0c7c86a01a9f25b Author: Mark Date: Wed Sep 17 19:15:43 2014 +0100 USB: storage: Add quirks for Entrega/Xircom USB to SCSI converters commit c80b4495c61636edc58fe1ce300f09f24db28e10 upstream. This patch adds quirks for Entrega Technologies (later Xircom PortGear) USB- SCSI converters. They use Shuttle Technology EUSB-01/EUSB-S1 chips. The US_FL_SCM_MULT_TARG quirk is needed to allow multiple devices on the SCSI chain to be accessed. Without it only the (single) device with SCSI ID 0 can be used. The standalone converter sold by Entrega had model number U1-SC25. Xircom acquired Entrega and re-branded the product line PortGear. The PortGear USB to SCSI Converter (model PGSCSI) is internally identical to the Entrega product, but later models may use a different USB ID. The Entrega-branded units have USB ID 1645:0007, as does my Xircom PGSCSI, but the Windows and Macintosh drivers also support 085A:0028. Entrega also sold the "Mac USB Dock", which provides two USB ports, a Mac (8-pin mini-DIN) serial port and a SCSI port. It appears to the computer as a four-port hub, USB-serial, and USB-SCSI converters. The USB-SCSI part may have initially used the same ID as the standalone U1-SC25 (1645:0007), but later production used 085A:0026. My Xircom PortGear PGSCSI has bcdDevice=0x0100. Units with bcdDevice=0x0133 probably also exist. This patch adds quirks for 1645:0007, 085A:0026 and 085A:0028. The Windows driver INF file also mentions 085A:0032 "PortStation SCSI Module", but I couldn't find any mention of that actually existing in the wild; perhaps it was cancelled before release? Signed-off-by: Mark Knibbs Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit eeaff23a9623c28319110aee703e6160d236b4af Author: Mark Date: Tue Sep 16 16:51:41 2014 +0100 USB: storage: Add quirk for Ariston Technologies iConnect USB to SCSI adapter commit b6a3ed677991558ce09046397a7c4d70530d15b3 upstream. Hi, The Ariston Technologies iConnect 025 and iConnect 050 (also known as e.g. iSCSI-50) are SCSI-USB converters which use Shuttle Technology/SCM Microsystems chips. Only the connectors differ; both have the same USB ID. The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other than 0. I don't have one of these, but based on the other entries for Shuttle/ SCM-based converters this patch is very likely correct. I used 0x0000 and 0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which bcdDevice value the products use. Signed-off-by: Mark Knibbs Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 7d81e603d04e7d98e1416236349817724354ae64 Author: Mark Date: Tue Sep 16 16:22:50 2014 +0100 USB: storage: Add quirk for Adaptec USBConnect 2000 USB-to-SCSI Adapter commit 67d365a57a51fb9dece6a5ceb504aa381cae1e5b upstream. The Adaptec USBConnect 2000 is another SCSI-USB converter which uses Shuttle Technology/SCM Microsystems chips. The US_FL_SCM_MULT_TARG quirk is required to use SCSI devices with ID other than 0. I don't have a USBConnect 2000, but based on the other entries for Shuttle/ SCM-based converters this patch is very likely correct. I used 0x0000 and 0x9999 for bcdDeviceMin and bcdDeviceMax because I'm not sure which bcdDevice value the product uses. Signed-off-by: Mark Knibbs Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 74cb172240786f18938ab882c552e49a05a2cbc8 Author: Mike Christie Date: Wed Sep 3 00:00:39 2014 -0500 libiscsi: fix potential buffer overrun in __iscsi_conn_send_pdu commit db9bfd64b14a3a8f1868d2164518fdeab1b26ad1 upstream. This patches fixes a potential buffer overrun in __iscsi_conn_send_pdu. This function is used by iscsi drivers and userspace to send iscsi PDUs/ commands. For login commands, we have a set buffer size. For all other commands we do not support data buffers. This was reported by Dan Carpenter here: http://www.spinics.net/lists/linux-scsi/msg66838.html Reported-by: Dan Carpenter Signed-off-by: Mike Christie Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings commit 5bd3c0477993f54bac2c4618655e4102ffe1fab4 Author: Trond Myklebust Date: Thu Sep 18 11:51:32 2014 -0400 NFSv4: Fix another bug in the close/open_downgrade code commit cd9288ffaea4359d5cfe2b8d264911506aed26a4 upstream. James Drew reports another bug whereby the NFS client is now sending an OPEN_DOWNGRADE in a situation where it should really have sent a CLOSE: the client is opening the file for O_RDWR, but then trying to do a downgrade to O_RDONLY, which is not allowed by the NFSv4 spec. Reported-by: James Drews Link: http://lkml.kernel.org/r/541AD7E5.8020409@engr.wisc.edu Fixes: aee7af356e15 (NFSv4: Fix problems with close in the presence...) Signed-off-by: Trond Myklebust [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 63cb95ba25b2377728536a8114cd05105dd370d4 Author: Joern Engel Date: Tue Sep 2 17:49:54 2014 -0400 iscsi-target: avoid NULL pointer in iscsi_copy_param_list failure commit 8ae757d09c45102b347a1bc2867f54ffc1ab8fda upstream. In iscsi_copy_param_list() a failed iscsi_param_list memory allocation currently invokes iscsi_release_param_list() to cleanup, and will promptly trigger a NULL pointer dereference. Instead, go ahead and return for the first iscsi_copy_param_list() failure case. Found by coverity. Signed-off-by: Joern Engel Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings commit 9c0e738c62a1b547590b5c4ce3ccf23cec371284 Author: Nicholas Bellinger Date: Wed Sep 17 11:45:17 2014 -0700 iscsi-target: Fix memory corruption in iscsit_logout_post_handler_diffcid commit b53b0d99d6fbf7d44330395349a895521cfdbc96 upstream. This patch fixes a bug in iscsit_logout_post_handler_diffcid() where a pointer used as storage for list_for_each_entry() was incorrectly being used to determine if no matching entry had been found. This patch changes iscsit_logout_post_handler_diffcid() to key off bool conn_found to determine if the function needs to exit early. Reported-by: Joern Engel Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings commit 1a4ba51a1d7def5f36b7dec2defd3c4ab27e9fb0 Author: Al Viro Date: Sat Sep 13 21:59:43 2014 -0400 be careful with nd->inode in path_init() and follow_dotdot_rcu() commit 4023bfc9f351a7994fb6a7d515476c320f94a574 upstream. in the former we simply check if dentry is still valid after picking its ->d_inode; in the latter we fetch ->d_inode in the same places where we fetch dentry and its ->d_seq, under the same checks. Signed-off-by: Al Viro [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit a7caf25487f8b0d85f0fa0eb9403301f2b35c1b1 Author: Ben Hutchings Date: Sun Oct 19 23:07:02 2014 +0100 vfs: Fold follow_mount_rcu() into follow_dotdot_rcu() This is needed before commit 4023bfc9f351 ('be careful with nd->inode in path_init() and follow_dotdot_rcu()'). A similar change was made upstream as part of commit b37199e626b3 ('rcuwalk: recheck mount_lock after mountpoint crossing attempts'). Signed-off-by: Ben Hutchings commit 035cbfd39f2f97948193448e2c27ccba84b3e30b Author: Al Viro Date: Sat Sep 13 21:55:46 2014 -0400 don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu() commit 7bd88377d482e1eae3c5329b12e33cfd664fa6a9 upstream. return the value instead, and have path_init() do the assignment. Broken by "vfs: Fix absolute RCU path walk failures due to uninitialized seq number", which was Cc-stable with 2.6.38+ as destination. This one should go where it went. To avoid dummy value returned in case when root is already set (it would do no harm, actually, since the only caller that doesn't ignore the return value is guaranteed to have nd->root *not* set, but it's more obvious that way), lift the check into callers. And do the same to set_root(), to keep them in sync. Signed-off-by: Al Viro [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by: Ben Hutchings commit 8601a7adf35479761c8682a23d4cad1a476ecc57 Author: Richard Larocque Date: Tue Sep 9 18:31:05 2014 -0700 alarmtimer: Lock k_itimer during timer callback commit 474e941bed9262f5fa2394f9a4a67e24499e5926 upstream. Locks the k_itimer's it_lock member when handling the alarm timer's expiry callback. The regular posix timers defined in posix-timers.c have this lock held during timout processing because their callbacks are routed through posix_timer_fn(). The alarm timers follow a different path, so they ought to grab the lock somewhere else. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Richard Cochran Cc: Prarit Bhargava Cc: Sharvil Nanavati Signed-off-by: Richard Larocque Signed-off-by: John Stultz Signed-off-by: Ben Hutchings commit 62bd84fa880482e1c9dbd0504345b9fc37dc4771 Author: Richard Larocque Date: Tue Sep 9 18:31:04 2014 -0700 alarmtimer: Do not signal SIGEV_NONE timers commit 265b81d23a46c39df0a735a3af4238954b41a4c2 upstream. Avoids sending a signal to alarm timers created with sigev_notify set to SIGEV_NONE by checking for that special case in the timeout callback. The regular posix timers avoid sending signals to SIGEV_NONE timers by not scheduling any callbacks for them in the first place. Although it would be possible to do something similar for alarm timers, it's simpler to handle this as a special case in the timeout. Prior to this patch, the alarm timer would ignore the sigev_notify value and try to deliver signals to the process anyway. Even worse, the sanity check for the value of sigev_signo is skipped when SIGEV_NONE was specified, so the signal number could be bogus. If sigev_signo was an unitialized value (as it often would be if SIGEV_NONE is used), then it's hard to predict which signal will be sent. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Richard Cochran Cc: Prarit Bhargava Cc: Sharvil Nanavati Signed-off-by: Richard Larocque Signed-off-by: John Stultz Signed-off-by: Ben Hutchings commit a1b01afa4324d35da3aaef069ac7220901e0e350 Author: Richard Larocque Date: Tue Sep 9 18:31:03 2014 -0700 alarmtimer: Return relative times in timer_gettime commit e86fea764991e00a03ff1e56409ec9cacdbda4c9 upstream. Returns the time remaining for an alarm timer, rather than the time at which it is scheduled to expire. If the timer has already expired or it is not currently scheduled, the it_value's members are set to zero. This new behavior matches that of the other posix-timers and the POSIX specifications. This is a change in user-visible behavior, and may break existing applications. Hopefully, few users rely on the old incorrect behavior. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Richard Cochran Cc: Prarit Bhargava Cc: Sharvil Nanavati Signed-off-by: Richard Larocque [jstultz: minor style tweak] Signed-off-by: John Stultz [bwh: Backported to 3.2: Add definition of alarm_expires_remaining() from commit 6cffe00f7d4e ('alarmtimer: Add functions for timerfd support')] Signed-off-by: Ben Hutchings commit d8aaaebbe614171cc12a3fe69a79315ac4e42d98 Author: Andrew Hunter Date: Thu Sep 4 14:17:16 2014 -0700 jiffies: Fix timeval conversion to jiffies commit d78c9300c51d6ceed9f6d078d4e9366f259de28c upstream. timeval_to_jiffies tried to round a timeval up to an integral number of jiffies, but the logic for doing so was incorrect: intervals corresponding to exactly N jiffies would become N+1. This manifested itself particularly repeatedly stopping/starting an itimer: setitimer(ITIMER_PROF, &val, NULL); setitimer(ITIMER_PROF, NULL, &val); would add a full tick to val, _even if it was exactly representable in terms of jiffies_ (say, the result of a previous rounding.) Doing this repeatedly would cause unbounded growth in val. So fix the math. Here's what was wrong with the conversion: we essentially computed (eliding seconds) jiffies = usec * (NSEC_PER_USEC/TICK_NSEC) by using scaling arithmetic, which took the best approximation of NSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC = x/(2^USEC_JIFFIE_SC), and computed: jiffies = (usec * x) >> USEC_JIFFIE_SC and rounded this calculation up in the intermediate form (since we can't necessarily exactly represent TICK_NSEC in usec.) But the scaling arithmetic is a (very slight) *over*approximation of the true value; that is, instead of dividing by (1 usec/ 1 jiffie), we effectively divided by (1 usec/1 jiffie)-epsilon (rounding down). This would normally be fine, but we want to round timeouts up, and we did so by adding 2^USEC_JIFFIE_SC - 1 before the shift; this would be fine if our division was exact, but dividing this by the slightly smaller factor was equivalent to adding just _over_ 1 to the final result (instead of just _under_ 1, as desired.) In particular, with HZ=1000, we consistently computed that 10000 usec was 11 jiffies; the same was true for any exact multiple of TICK_NSEC. We could possibly still round in the intermediate form, adding something less than 2^USEC_JIFFIE_SC - 1, but easier still is to convert usec->nsec, round in nanoseconds, and then convert using time*spec*_to_jiffies. This adds one constant multiplication, and is not observably slower in microbenchmarks on recent x86 hardware. Tested: the following program: int main() { struct itimerval zero = {{0, 0}, {0, 0}}; /* Initially set to 10 ms. */ struct itimerval initial = zero; initial.it_interval.tv_usec = 10000; setitimer(ITIMER_PROF, &initial, NULL); /* Save and restore several times. */ for (size_t i = 0; i < 10; ++i) { struct itimerval prev; setitimer(ITIMER_PROF, &zero, &prev); /* on old kernels, this goes up by TICK_USEC every iteration */ printf("previous value: %ld %ld %ld %ld\n", prev.it_interval.tv_sec, prev.it_interval.tv_usec, prev.it_value.tv_sec, prev.it_value.tv_usec); setitimer(ITIMER_PROF, &prev, NULL); } return 0; } Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Paul Turner Cc: Richard Cochran Cc: Prarit Bhargava Reviewed-by: Paul Turner Reported-by: Aaron Jacobs Signed-off-by: Andrew Hunter [jstultz: Tweaked to apply to 3.17-rc] Signed-off-by: John Stultz [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit 2e10b8a67f891a1d9b86ca72321259a7f63d3b42 Author: Thomas Gleixner Date: Thu Sep 11 23:44:35 2014 +0200 futex: Unlock hb->lock in futex_wait_requeue_pi() error path commit 13c42c2f43b19aab3195f2d357db00d1e885eaa8 upstream. futex_wait_requeue_pi() calls futex_wait_setup(). If futex_wait_setup() succeeds it returns with hb->lock held and preemption disabled. Now the sanity check after this does: if (match_futex(&q.key, &key2)) { ret = -EINVAL; goto out_put_keys; } which releases the keys but does not release hb->lock. So we happily return to user space with hb->lock held and therefor preemption disabled. Unlock hb->lock before taking the exit route. Reported-by: Dave "Trinity" Jones Signed-off-by: Thomas Gleixner Reviewed-by: Darren Hart Reviewed-by: Davidlohr Bueso Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1409112318500.4178@nanos Signed-off-by: Thomas Gleixner [bwh: Backported to 3.2: queue_unlock() takes two parameters] Signed-off-by: Ben Hutchings commit 29a8d1a41767ad86f7caca17762a7fddf3207201 Author: Hans de Goede Date: Thu Sep 11 10:10:26 2014 -0700 Input: i8042 - add nomux quirk for Avatar AVIU-145A6 commit d2682118f4bb3ceb835f91c1a694407a31bb7378 upstream. The sys_vendor / product_name are somewhat generic unfortunately, so this may lead to some false positives. But nomux usually does no harm, where as not having it clearly is causing problems on the Avatar AVIU-145A6. https://bugzilla.kernel.org/show_bug.cgi?id=77391 Reported-by: Hugo P Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 2f7cf95e2f72da7a3f46634413688c1ae6e4fe29 Author: Hans de Goede Date: Wed Sep 10 13:53:37 2014 -0700 Input: i8042 - add Fujitsu U574 to no_timeout dmi table commit cc18a69c92d0972bc2fc5a047ee3be1e8398171b upstream. https://bugzilla.kernel.org/show_bug.cgi?id=69731 Reported-by: Jason Robinson Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit cd2b663832bf1eeb2f5d15e092546ae0c0d58135 Author: Mathias Nyman Date: Thu Sep 11 13:55:48 2014 +0300 xhci: Fix null pointer dereference if xhci initialization fails commit c207e7c50f31113c24a9f536fcab1e8a256985d7 upstream. If xhci initialization fails before the roothub bandwidth domains (xhci->rh_bw[i]) are allocated it will oops when trying to access rh_bw members in xhci_mem_cleanup(). Reported-by: Manuel Reimer Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 2a163ac939fd6a7c8f96bb577a45e3f5d97a382d Author: Mark Date: Thu Sep 11 13:15:45 2014 +0100 storage: Add single-LUN quirk for Jaz USB Adapter commit c66f1c62e85927357e7b3f4c701614dcb5c498a2 upstream. The Iomega Jaz USB Adapter is a SCSI-USB converter cable. The hardware seems to be identical to e.g. the Microtech XpressSCSI, using a Shuttle/ SCM chip set. However its firmware restricts it to only work with Jaz drives. On connecting the cable a message like this appears four times in the log: reset full speed USB device number 4 using uhci_hcd That's non-fatal but the US_FL_SINGLE_LUN quirk fixes it. Signed-off-by: Mark Knibbs Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 1c20e37c1d0975eca131a6b1d86f3a50d3e4caac Author: Joe Lawrence Date: Wed Sep 10 15:07:50 2014 -0400 usb: hub: take hub->hdev reference when processing from eventlist commit c605f3cdff53a743f6d875b76956b239deca1272 upstream. During surprise device hotplug removal tests, it was observed that hub_events may try to call usb_lock_device on a device that has already been freed. Protect the usb_device by taking out a reference (under the hub_event_lock) when hub_events pulls it off the list, returning the reference after hub_events is finished using it. Signed-off-by: Joe Lawrence Suggested-by: David Bulkow for using kref Suggested-by: Alan Stern for placement Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 9a91e2d1a2a7c521b1ca22dd4216bc1f4fb81cbc Author: John Sung Date: Tue Sep 9 10:06:51 2014 -0700 Input: serport - add compat handling for SPIOCSTYPE ioctl commit a80d8b02751060a178bb1f7a6b7a93645a7a308b upstream. When running a 32-bit inputattach utility in a 64-bit system, there will be error code "inputattach: can't set device type". This is caused by the serport device driver not supporting compat_ioctl, so that SPIOCSTYPE ioctl fails. Signed-off-by: John Sung Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 3ab3b3b67868458de3b047e199c0efe8119ef0de 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: Ben Hutchings commit 7e8155c14784ed219a23b2ba01eedf946b27cb00 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: Ben Hutchings commit df0fddbf7ec235d49847efcda0d3c901d7964ba5 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: Ben Hutchings commit 488dbde366f437720b55cd29571219cebc89251b Author: Ilya Dryomov Date: Thu Jan 9 20:08:21 2014 +0200 libceph: rename ceph_msg::front_max to front_alloc_len commit 3cea4c3071d4e55e9d7356efe9d0ebf92f0c2204 upstream. Rename front_max field of struct ceph_msg to front_alloc_len to make its purpose more clear. Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit babe91ef97b39c84a9356a4044cf87c419c98c83 Author: Dmitry Torokhov Date: Sat Aug 30 13:51:06 2014 -0700 Input: synaptics - add support for ForcePads commit 5715fc764f7753d464dbe094b5ef9cffa6e479a4 upstream. ForcePads are found on HP EliteBook 1040 laptops. They lack any kind of physical buttons, instead they generate primary button click when user presses somewhat hard on the surface of the touchpad. Unfortunately they also report primary button click whenever there are 2 or more contacts on the pad, messing up all multi-finger gestures (2-finger scrolling, multi-finger tapping, etc). To cope with this behavior we introduce a delay (currently 50 msecs) in reporting primary press in case more contacts appear. Reviewed-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 189613e5ef510bc6f58feeb023b57d71c1970a4c Author: Cong Wang Date: Tue Sep 2 15:27:20 2014 -0700 perf: Fix a race condition in perf_remove_from_context() commit 3577af70a2ce4853d58e57d832e687d739281479 upstream. We saw a kernel soft lockup in perf_remove_from_context(), it looks like the `perf` process, when exiting, could not go out of the retry loop. Meanwhile, the target process was forking a child. So either the target process should execute the smp function call to deactive the event (if it was running) or it should do a context switch which deactives the event. It seems we optimize out a context switch in perf_event_context_sched_out(), and what's more important, we still test an obsolete task pointer when retrying, so no one actually would deactive that event in this situation. Fix it directly by reloading the task pointer in perf_remove_from_context(). This should cure the above soft lockup. Signed-off-by: Cong Wang Signed-off-by: Cong Wang Signed-off-by: Peter Zijlstra Cc: Paul Mackerras Cc: Arnaldo Carvalho de Melo Cc: Linus Torvalds Link: http://lkml.kernel.org/r/1409696840-843-1-git-send-email-xiyou.wangcong@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit 126531ff8a7a8bec5517b6baaada5b2e7560fc89 Author: Thomas Pugliese Date: Thu Aug 7 15:45:35 2014 -0500 uwb: init beacon cache entry before registering uwb device commit 675f0ab2fe5a0f7325208e60b617a5f32b86d72c upstream. Make sure the uwb_dev->bce entry is set before calling uwb_dev_add in uwbd_dev_onair so that usermode will only see the device after it is properly initialized. This fixes a kernel panic that can occur if usermode tries to access the IEs sysfs attribute of a UWB device before the driver has had a chance to set the beacon cache entry. Signed-off-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 95c263be9920e6993750b98007b84c6e724e9e93 Author: Taylor Braun-Jones Date: Thu Aug 7 14:25:06 2014 -0400 USB: ftdi_sio: Add support for GE Healthcare Nemo Tracker device commit 9c491c372d677b6420e0f8c6361fe422791662cc upstream. Signed-off-by: Taylor Braun-Jones Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 0dbe2cea0fb186417d42561df9f687c02b0fabfe Author: Hans de Goede Date: Mon Sep 8 14:39:52 2014 -0700 Input: elantech - fix detection of touchpad on ASUS s301l commit 271329b3c798b2102120f5df829071c211ef00ed upstream. Adjust Elantech signature validation to account fo rnewer models of touchpads. Reported-and-tested-by: Màrius Monton Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit 3d13e2b6962460a2979f6f12a6fba3310c5ce479 Author: Felipe Balbi Date: Wed Aug 27 16:38:04 2014 -0500 usb: host: xhci: fix compliance mode workaround commit 96908589a8b2584b1185f834d365f5cc360e8226 upstream. Commit 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) implemented a workaround for a known issue with Texas Instruments' USB 3.0 redriver IC but it left a condition where any xHCI host would be taken out of reset if port was placed in compliance mode and there was no device connected to the port. That condition would trigger a fake connection to a non-existent device so that usbcore would trigger a warm reset of the port, thus taking the link out of reset. This has the side-effect of preventing any xHCI host connected to a Linux machine from starting and running the USB 3.0 Electrical Compliance Suite because the port will mysteriously taken out of compliance mode and, thus, xHCI won't step through the necessary compliance patterns for link validation. This patch fixes the issue by just adding a missing check for XHCI_COMP_MODE_QUIRK inside xhci_hub_report_usb3_link_state() when PORT_CAS isn't set. This patch should be backported to all kernels containing commit 71c731a. Fixes: 71c731a (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) Cc: Alexis R. Cortes Signed-off-by: Felipe Balbi Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: - s/xhci_hub_report_usb3_link_state/xhci_hub_report_link_state/ - s/raw_port_status/temp/ - Adjust indentation] Signed-off-by: Ben Hutchings commit dfc9c24ea8413089d41d0dbbaa93b434dbbec0ad Author: Alex Deucher Date: Mon Sep 8 13:55:51 2014 -0400 drm/radeon: add connector quirk for fujitsu board commit 1952f24d0fa6292d65f886887af87ba8ac79b3ba upstream. Vbios connector table lists non-existent VGA port. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83184 Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit 113e5bc489cc71ceb832206dddff35163f34e6fe Author: Murali Karicheri Date: Fri Sep 5 13:21:00 2014 -0400 ahci: add pcid for Marvel 0x9182 controller commit c5edfff9db6f4d2c35c802acb4abe0df178becee upstream. Keystone K2E EVM uses Marvel 0x9182 controller. This requires support for the ID in the ahci driver. Signed-off-by: Murali Karicheri Signed-off-by: Tejun Heo Cc: Santosh Shilimkar Signed-off-by: Ben Hutchings commit fbe002f7af62511e81f602497343c5a4bb8ab583 Author: Felipe Balbi Date: Tue Sep 2 14:57:20 2014 -0500 usb: dwc3: core: fix order of PM runtime calls commit fed33afce0eda44a46ae24d93aec1b5198c0bac4 upstream. Currently, we disable pm_runtime before all register accesses are done, this is dangerous and might lead to abort exceptions due to the driver trying to access a register which is clocked by a clock which was long gated. Fix that by moving pm_runtime_put_sync() and pm_runtime_disable() as the last thing we do before returning from our ->remove() method. Fixes: 72246da (usb: Introduce DesignWare USB3 DRD Driver) Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit 53de22a51dc90050aa5d83fd75a2bce28bc90f9e Author: Felipe Balbi Date: Fri Oct 11 08:34:28 2013 -0500 usb: dwc3: core: use pm_runtime_put_sync() on remove commit 16b972a592ea2c9a3c2a3c12238de650fd4043a9 upstream. We are going to disable runtime_pm and we're removing the driver, we must disable the device now. Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit 5df1eb90953a86127ca130d90724819383f896da 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: Ben Hutchings commit a288cafeceb6e18ba4fd10ec8d3270593472cca6 Author: Keith Busch Date: Tue Aug 26 09:05:36 2014 -0600 block: Fix dev_t minor allocation lifetime commit 2da78092dda13f1efd26edbbf99a567776913750 upstream. Releases the dev_t minor when all references are closed to prevent another device from acquiring the same major/minor. Since the partition's release may be invoked from call_rcu's soft-irq context, the ext_dev_idr's mutex had to be replaced with a spinlock so as not so sleep. Signed-off-by: Keith Busch Signed-off-by: Jens Axboe [bwh: Backported to 3.2: - Adjust filename - idr insertion API is different, and blk_alloc_devt() is preallocating a node in a different way] Signed-off-by: Ben Hutchings commit 1cc8e21690688b24b0b9388dbb14e1d2cf4f94b4 Author: Jeff Moyer Date: Tue Sep 2 13:17:00 2014 -0400 aio: add missing smp_rmb() in read_events_ring commit 2ff396be602f10b5eab8e73b24f20348fa2de159 upstream. We ran into a case on ppc64 running mariadb where io_getevents would return zeroed out I/O events. After adding instrumentation, it became clear that there was some missing synchronization between reading the tail pointer and the events themselves. This small patch fixes the problem in testing. Thanks to Zach for helping to look into this, and suggesting the fix. Signed-off-by: Jeff Moyer Signed-off-by: Benjamin LaHaise [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by: Ben Hutchings commit 11d3b506cc0db26d2f2078bd4df88803cd06c819 Author: Ross Lagerwall Date: Mon Aug 18 10:41:36 2014 +0100 xen/manage: Always freeze/thaw processes when suspend/resuming commit 61a734d305e16944b42730ef582a7171dc733321 upstream. Always freeze processes when suspending and thaw processes when resuming to prevent a race noticeable with HVM guests. This prevents a deadlock where the khubd kthread (which is designed to be freezable) acquires a usb device lock and then tries to allocate memory which requires the disk which hasn't been resumed yet. Meanwhile, the xenwatch thread deadlocks waiting for the usb device lock. Freezing processes fixes this because the khubd thread is only thawed after the xenwatch thread finishes resuming all the devices. Signed-off-by: Ross Lagerwall Signed-off-by: David Vrabel [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit dd27db6dbfd3ccac0806576b572a86f213a59208 Author: Takashi Iwai Date: Tue Sep 2 07:21:56 2014 +0200 ALSA: hda - Fix COEF setups for ALC1150 codec commit acf08081adb5e8fe0519eb97bb49797ef52614d6 upstream. ALC1150 codec seems to need the COEF- and PLL-setups just like its compatible ALC882 codec. Some machines (e.g. SunMicro X10SAT) show the problem like too low output volumes unless the COEF setup is applied. Reported-and-tested-by: Dana Goyette Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit c81ddee59127ad2900e623d8fe5e839c48e1a027 Author: Thomas Hellstrom Date: Thu Aug 28 11:53:23 2014 +0200 drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle commit f01ea0c3d9db536c64d47922716d8b3b8f21d850 upstream. The code waiting for fifo idle was incorrect and could possibly spin forever under certain circumstances. Signed-off-by: Thomas Hellstrom Reported-by: Mark Sheldon Reviewed-by: Jakob Bornecrantz Reivewed-by: Mark Sheldon Signed-off-by: Ben Hutchings commit 45563df0222abb0c85b9a9ef22aadfc17475d9cf Author: Bjørn Mork Date: Thu Aug 28 15:08:16 2014 +0200 USB: sierra: add 1199:68AA device ID commit 5b3da69285c143b7ea76b3b9f73099ff1093ab73 upstream. This VID:PID is used for some Direct IP devices behaving identical to the already supported 0F3D:68AA devices. Reported-by: Lars Melin Signed-off-by: Bjørn Mork Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit 8beeac9293eb3e6842fae5e304627317ce6db0e2 Author: Bjørn Mork Date: Thu Aug 28 14:11:23 2014 +0200 USB: sierra: avoid CDC class functions on "68A3" devices commit 049255f51644c1105775af228396d187402a5934 upstream. Sierra Wireless Direct IP devices using the 68A3 product ID can be configured for modes including a CDC ECM class function. The known example uses interface numbers 12 and 13 for the ECM control and data interfaces respectively, consistent with CDC MBIM function interface numbering on other Sierra devices. It seems cleaner to restrict this driver to the ff/ff/ff vendor specific interfaces rather than increasing the already long interface number blacklist. This should be more future proof if Sierra adds more class functions using interface numbers not yet in the blacklist. Signed-off-by: Bjørn Mork Signed-off-by: Johan Hovold [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 5a8ac404d318410f3a2776631b3167b3ff8bcb6e Author: Johan Hovold Date: Mon Aug 18 18:33:11 2014 +0200 USB: ftdi_sio: add support for NOVITUS Bono E thermal printer commit ee444609dbae8afee420c3243ce4c5f442efb622 upstream. Add device id for NOVITUS Bono E thermal printer. Reported-by: Emanuel Koczwara Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit 0eea2faae2ace3533f18adbac4ebefe2c9d37e67 Author: Emmanuel Grumbach Date: Sun Aug 31 22:11:11 2014 +0300 Revert "iwlwifi: dvm: don't enable CTS to self" commit f47f46d7b09cf1d09e4b44b6cc4dd7d68a08028c upstream. This reverts commit 43d826ca5979927131685cc2092c7ce862cb91cd. This commit caused packet loss. Signed-off-by: Emmanuel Grumbach [bwh: Backported to 3.2: - Adjust filename - Condition for RXON_FLG_SELF_CTS_EN in iwlagn_commit_rxon() was different] Signed-off-by: Ben Hutchings commit 39e780f75c52d4afe4b8e1f2833b042c2473ae15 Author: James Ralston Date: Wed Aug 27 14:31:58 2014 -0700 ata_piix: Add Device IDs for Intel 9 Series PCH commit 6cad1376954e591c3c41500c4e586e183e7ffe6d upstream. This patch adds the IDE mode SATA Device IDs for the Intel 9 Series PCH. Signed-off-by: James Ralston Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit 1f5f42a581bf7d12f49c8e9923f73969825de89b Author: James Ralston Date: Wed Aug 27 14:29:07 2014 -0700 ahci: Add Device IDs for Intel 9 Series PCH commit 1b071a0947dbce5c184c12262e02540fbc493457 upstream. This patch adds the AHCI mode SATA Device IDs for the Intel 9 Series PCH. Signed-off-by: James Ralston Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit 323d7ad8b6e79ac5fd43a897e6197fe018d4cd79 Author: Mathias Krause Date: Wed Aug 27 18:41:19 2014 +0200 drm/i915: Remove bogus __init annotation from DMI callbacks commit bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a upstream. The __init annotations for the DMI callback functions are wrong as this code can be called even after the module has been initialized, e.g. like this: # echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove # modprobe i915 # echo 1 > /sys/bus/pci/rescan The first command will remove the PCI device from the kernel's device list so the second command won't see it right away. But as it registers a PCI driver it'll see it on the third command. If the system happens to match one of the DMI table entries we'll try to call a function in long released memory and generate an Oops, at best. Fix this by removing the bogus annotation. Modpost should have caught that one but it ignores section reference mismatches from the .rodata section. :/ Fixes: 25e341cfc33d ("drm/i915: quirk away broken OpRegion VBT") Fixes: 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT...") Fixes: 425d244c8670 ("drm/i915: ignore LVDS on intel graphics systems...") Signed-off-by: Mathias Krause Cc: Daniel Vetter Cc: Duncan Laurie Cc: Jarod Wilson Cc: Rusty Russell # Can modpost be fixed? Signed-off-by: Jani Nikula [bwh: Backported to 3.2: drop inapplicable change in intel_crt.c] Signed-off-by: Ben Hutchings commit 905c7c717c399ac7e57923d85c75fb86f70381ca Author: Mark Brown Date: Tue Aug 26 12:12:17 2014 +0100 regmap: Fix handling of volatile registers for format_write() chips commit 5844a8b9d98ec11ce1d77610daacf3f0a0e14715 upstream. A previous over-zealous factorisation of code means that we only treat registers as volatile if they are readable. For most devices this is fine since normally most registers can be read and volatility implies readability but for format_write() devices where there is no readback from the hardware and we use volatility to mean simply uncacheability this means that we end up treating all registers as cacheble. A bigger refactoring of the code to clarify this is in order but as a fix make a minimal change and only check readability when checking volatility if there is no format_write() operation defined for the device. Signed-off-by: Mark Brown Tested-by: Lars-Peter Clausen Signed-off-by: Ben Hutchings commit 88d4b8a68967090fd4e7e85b59fa0e2fd9a38965 Author: Wolfram Sang Date: Mon Jan 30 15:08:16 2012 +0100 regmap: if format_write is used, declare all registers as "unreadable" commit 4191f19792bf91267835eb090d970e9cd6277a65 upstream. Using .format_write means, we have a custom function to write to the chip, but not to read back. Also, mark registers as "not precious" and "not volatile" which is implicit because we cannot read them. Make those functions use 'regmap_readable' to reuse the checks done there. Signed-off-by: Wolfram Sang Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings commit a7b97034f762c24849a507fda181dc47198a7f48 Author: Aurelien Jarno Date: Sun Jul 20 19:58:23 2014 +0200 MIPS: ZBOOT: add missing include commit 29593fd5a8149462ed6fad0d522234facdaee6c8 upstream. Commit dc4d7b37 (MIPS: ZBOOT: gather string functions into string.c) moved the string related functions into a separate file, which might cause the following build error, depending on the configuration: | CC arch/mips/boot/compressed/decompress.o | In file included from linux/arch/mips/boot/compressed/../../../../lib/decompress_unxz.c:234:0, | from linux/arch/mips/boot/compressed/decompress.c:67: | linux/arch/mips/boot/compressed/../../../../lib/xz/xz_dec_stream.c: In function 'fill_temp': | linux/arch/mips/boot/compressed/../../../../lib/xz/xz_dec_stream.c:162:2: error: implicit declaration of function 'memcpy' [-Werror=implicit-function-declaration] | cc1: some warnings being treated as errors | linux/scripts/Makefile.build:308: recipe for target 'arch/mips/boot/compressed/decompress.o' failed | make[6]: *** [arch/mips/boot/compressed/decompress.o] Error 1 | linux/arch/mips/Makefile:308: recipe for target 'vmlinuz' failed It does not fail with the standard configuration, as when CONFIG_DYNAMIC_DEBUG is not enabled gets included in include/linux/dynamic_debug.h. There might be other ways for it to get indirectly included. We can't add the include directly in xz_dec_stream.c as some architectures might want to use a different version for the boot/ directory (see for example arch/x86/boot/string.h). Signed-off-by: Aurelien Jarno Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7420/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings commit 541d1dfef032bc1b7cd92f3093c1ad4f39605a9d Author: Larry Finger Date: Sun Aug 24 17:49:43 2014 -0500 rtlwifi: rtl8192cu: Add new ID commit c66517165610b911e4c6d268f28d8c640832dbd1 upstream. The Sitecom WLA-2102 adapter uses this driver. Reported-by: Nico Baggus Signed-off-by: Larry Finger Cc: Nico Baggus Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 30952365eec776b5251377f6ec343db0d26a6a1a Author: Christian Borntraeger Date: Wed Aug 6 16:17:58 2014 +0200 KVM: s390: Fix user triggerable bug in dead code commit 614a80e474b227cace52fd6e3c790554db8a396e upstream. In the early days, we had some special handling for the KVM_EXIT_S390_SIEIC exit, but this was gone in 2009 with commit d7b0b5eb3000 (KVM: s390: Make psw available on all exits, not just a subset). Now this switch statement is just a sanity check for userspace not messing with the kvm_run structure. Unfortunately, this allows userspace to trigger a kernel BUG. Let's just remove this switch statement. Signed-off-by: Christian Borntraeger Reviewed-by: Cornelia Huck Reviewed-by: David Hildenbrand Signed-off-by: Ben Hutchings commit 9e55f15dff80cadac01296cbf805ee0fb414ff58 Author: Alban Crequy Date: Mon Aug 18 12:20:20 2014 +0100 cgroup: reject cgroup names with ' ' commit 71b1fb5c4473a5b1e601d41b109bdfe001ec82e0 upstream. /proc//cgroup contains one cgroup path on each line. If cgroup names are allowed to contain "\n", applications cannot parse /proc//cgroup safely. Signed-off-by: Alban Crequy Signed-off-by: Tejun Heo [bwh: Backported to 3.2: - Adjust context - We have to get the name from the dentry pointer] Signed-off-by: Ben Hutchings commit ba895cc68b8cd42daa559576783af546fd79d59b Author: Honggang Li Date: Tue Aug 12 21:36:15 2014 +0800 percpu: free percpu allocation info for uniprocessor system commit 3189eddbcafcc4d827f7f19facbeddec4424eba8 upstream. Currently, only SMP system free the percpu allocation info. Uniprocessor system should free it too. For example, one x86 UML virtual machine with 256MB memory, UML kernel wastes one page memory. Signed-off-by: Honggang Li Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit caef3d5a04fd43316fccb25e93d350605ed54a23 Author: Tejun Heo Date: Fri Aug 15 16:06:10 2014 -0400 percpu: perform tlb flush after pcpu_map_pages() failure commit 849f5169097e1ba35b90ac9df76b5bb6f9c0aabd upstream. If pcpu_map_pages() fails midway, it unmaps the already mapped pages. Currently, it doesn't flush tlb after the partial unmapping. This may be okay in most cases as the established mapping hasn't been used at that point but it can go wrong and when it goes wrong it'd be extremely difficult to track down. Flush tlb after the partial unmapping. Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit c039250e175f15b4fa15c2aa6ae0b14162eff27d Author: Tejun Heo Date: Fri Aug 15 16:06:06 2014 -0400 percpu: fix pcpu_alloc_pages() failure path commit f0d279654dea22b7a6ad34b9334aee80cda62cde upstream. When pcpu_alloc_pages() fails midway, pcpu_free_pages() is invoked to free what has already been allocated. The invocation is across the whole requested range and pcpu_free_pages() will try to free all non-NULL pages; unfortunately, this is incorrect as pcpu_get_pages_and_bitmap(), unlike what its comment suggests, doesn't clear the pages array and thus the array may have entries from the previous invocations making the partial failure path free incorrect pages. Fix it by open-coding the partial freeing of the already allocated pages. Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit 6856061748aced168123cc77a8c16ada57825719 Author: Eliad Peller Date: Wed Jun 11 10:23:35 2014 +0300 regulatory: add NUL to alpha2 commit a5fe8e7695dc3f547e955ad2b662e3e72969e506 upstream. alpha2 is defined as 2-chars array, but is used in multiple places as string (e.g. with nla_put_string calls), which might leak kernel data. Solve it by simply adding an extra char for the NULL terminator, making such operations safe. Signed-off-by: Eliad Peller Signed-off-by: Johannes Berg [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings