summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-02-06hpfs: remember free spaceMikulas Patocka
commit 2cbe5c76fc5e38e9af4b709593146e4b8272b69e upstream. Previously, hpfs scanned all bitmaps each time the user asked for free space using statfs. This patch changes it so that hpfs scans the bitmaps only once, remembes the free space and on next invocation of statfs it returns the value instantly. New versions of wine are hammering on the statfs syscall very heavily, making some games unplayable when they're stored on hpfs, with load times in minutes. This should be backported to the stable kernels because it fixes user-visible problem (excessive level load times in wine). Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabledStephen Warren
(This is upstream 75fae117a5db "ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled", backported to stable 3.10 through 3.12. 3.13 and later can take the original patch.) Commit 384a48d71520 "ALSA: hda: HDMI: Support codecs with fewer cvts than pins" dynamically enabled each pin widget's PIN_OUT only when the pin was actively in use. This was required on certain NVIDIA CODECs for correct operation. Specifically, if multiple pin widgets each had their mux input select the same audio converter widget and each pin widget had PIN_OUT enabled, then only one of the pin widgets would actually receive the audio, and often not the one the user wanted! However, this apparently broke some Intel systems, and commit 6169b673618b "ALSA: hda - Always turn on pins for HDMI/DP" reverted the dynamic setting of PIN_OUT. This in turn broke the afore-mentioned NVIDIA CODECs. This change supports either dynamic or static handling of PIN_OUT, selected by a flag set up during CODEC initialization. This flag is enabled for all recent NVIDIA GPUs. Reported-by: Uosis <uosisl@gmail.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ALSA: hda - hdmi: introduce patch_nvhdmi()Anssi Hannula
(This is a backport of *part* of upstream 611885bc963a "ALSA: hda - hdmi: Disallow unsupported 2ch remapping on NVIDIA codecs" to stable 3.10 through 3.12. Later stable already contain all of the original patch.) Mainline commit 611885bc963a "ALSA: hda - hdmi: Disallow unsupported 2ch remapping on NVIDIA codecs" introduces function patch_nvhdmi(). That function is edited by 75fae117a5db "ALSA: hda/hdmi - allow PIN_OUT to be dynamically enabled". In order to backport the PIN_OUT patch, I am first back-porting just the addition of function patch_nvhdmi(), so that the conflicts applying the PIN_OUT patch are simplified. Ideally, one might backport all of 611885bc963a. However, that commit doesn't apply to stable kernels, since it relies on a chain of other patches which implement new features. Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by: Takashi Iwai <tiwai@suse.de> [swarren, extracted just a small part of the original patch] Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ALSA: hda - Don't set indep_hp flag for old AD codecsTakashi Iwai
commit cbd209f41ea5f39394de5c1fe2dd9aa54a9c5744 upstream. Some old AD codecs don't like the independent HP handling, either it contains a single DAC (AD1981) or it mandates the mixer routing (AD1986A). This patch removes the indep_hp flag for such codecs. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68081 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06KVM: PPC: e500: Fix bad address type in deliver_tlb_misss()Mihai Caraman
commit 70713fe315ed14cd1bb07d1a7f33e973d136ae3d upstream. Use gva_t instead of unsigned int for eaddr in deliver_tlb_miss(). Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06KVM: PPC: Book3S HV: use xics_wake_cpu only when definedAndreas Schwab
commit 48eaef0518a565d3852e301c860e1af6a6db5a84 upstream. Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06parisc: fix cache-flushingHelge Deller
commit 57737c49dd72c96cfbcd4f66559f3ffc399aeb4f upstream. This commit: f8dae00684d678afa13041ef170cecfd1297ed40: parisc: Ensure full cache coherency for kmap/kunmap caused negative caching side-effects, e.g. hanging processes with expect and too many inequivalent alias messages from flush_dcache_page() on Debian 5 systems. This patch now partly reverts it and has been in production use on our debian buildd makeservers since a week without any major problems. Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06alpha: fix broken network checksumMikulas Patocka
commit 0ef38d70d4118b2ce1a538d14357be5ff9dc2bbd upstream. The patch 3ddc5b46a8e90f3c9251338b60191d0a804b0d92 breaks networking on alpha (there is a follow-up fix 5cfe8f1ba5eebe6f4b6e5858cdb1a5be4f3272a6, but networking is still broken even with the second patch). The patch 3ddc5b46a8e90f3c9251338b60191d0a804b0d92 makes csum_partial_copy_from_user check the pointer with access_ok. However, csum_partial_copy_from_user is called also from csum_partial_copy_nocheck and csum_partial_copy_nocheck is called on kernel pointers and it is supposed not to check pointer validity. This bug results in ssh session hangs if the system is loaded and bulk data are printed to ssh terminal. This patch fixes csum_partial_copy_nocheck to call set_fs(KERNEL_DS), so that access_ok in csum_partial_copy_from_user accepts kernel-space addresses. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06inet_diag: fix inet_diag_dump_icsk() timewait socket state logicNeal Cardwell
[ Based upon upstream commit 70315d22d3c7383f9a508d0aab21e2eb35b2303a ] Fix inet_diag_dump_icsk() to reflect the fact that both TIME_WAIT and FIN_WAIT2 connections are represented by inet_timewait_sock (not just TIME_WAIT). Thus: (a) We need to iterate through the time_wait buckets if the user wants either TIME_WAIT or FIN_WAIT2. (Before fixing this, "ss -nemoi state fin-wait-2" would not return any sockets, even if there were some in FIN_WAIT2.) (b) We need to check tw_substate to see if the user wants to dump sockets in the particular substate (TIME_WAIT or FIN_WAIT2) that a given connection is in. (Before fixing this, "ss -nemoi state time-wait" would actually return sockets in state FIN_WAIT2.) An analogous fix is in v3.13: 70315d22d3c7383f9a508d0aab21e2eb35b2303a ("inet_diag: fix inet_diag_dump_icsk() to use correct state for timewait sockets") but that patch is quite different because 3.13 code is very different in this area due to the unification of TCP hash tables in 05dbc7b ("tcp/dccp: remove twchain") in v3.13-rc1. I tested that this applies cleanly between v3.3 and v3.12, and tested that it works in both 3.3 and 3.12. It does not apply cleanly to 3.2 and earlier (though it makes semantic sense), and semantically is not the right fix for 3.13 and beyond (as mentioned above). Signed-off-by: Neal Cardwell <ncardwell@google.com> Cc: Eric Dumazet <edumazet@google.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06net: gre: use icmp_hdr() to get inner ip headerDuan Jiong
[ Upstream commit c0c0c50ff7c3e331c90bab316d21f724fb9e1994 ] When dealing with icmp messages, the skb->data points the ip header that triggered the sending of the icmp message. In gre_cisco_err(), the parse_gre_header() is called, and the iptunnel_pull_header() is called to pull the skb at the end of the parse_gre_header(), so the skb->data doesn't point the inner ip header. Unfortunately, the ipgre_err still needs those ip addresses in inner ip header to look up tunnel by ip_tunnel_lookup(). So just use icmp_hdr() to get inner ip header instead of skb->data. Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06xen-netfront: fix resource leak in netfrontAnnie Li
[ Upstream commit cefe0078eea52af17411eb1248946a94afb84ca5 ] This patch removes grant transfer releasing code from netfront, and uses gnttab_end_foreign_access to end grant access since gnttab_end_foreign_access_ref may fail when the grant entry is currently used for reading or writing. * clean up grant transfer code kept from old netfront(2.6.18) which grants pages for access/map and transfer. But grant transfer is deprecated in current netfront, so remove corresponding release code for transfer. * fix resource leak, release grant access (through gnttab_end_foreign_access) and skb for tx/rx path, use get_page to ensure page is released when grant access is completed successfully. Xen-blkfront/xen-tpmfront/xen-pcifront also have similar issue, but patches for them will be created separately. V6: Correct subject line and commit message. V5: Remove unecessary change in xennet_end_access. V4: Revert put_page in gnttab_end_foreign_access, and keep netfront change in single patch. V3: Changes as suggestion from David Vrabel, ensure pages are not freed untill grant acess is ended. V2: Improve patch comments. Signed-off-by: Annie Li <annie.li@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06net: Fix memory leak if TPROXY used with TCP early demuxHolger Eitzenberger
[ Upstream commit a452ce345d63ddf92cd101e4196569f8718ad319 ] I see a memory leak when using a transparent HTTP proxy using TPROXY together with TCP early demux and Kernel v3.8.13.15 (Ubuntu stable): unreferenced object 0xffff88008cba4a40 (size 1696): comm "softirq", pid 0, jiffies 4294944115 (age 8907.520s) hex dump (first 32 bytes): 0a e0 20 6a 40 04 1b 37 92 be 32 e2 e8 b4 00 00 .. j@..7..2..... 02 00 07 01 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff810b710a>] kmem_cache_alloc+0xad/0xb9 [<ffffffff81270185>] sk_prot_alloc+0x29/0xc5 [<ffffffff812702cf>] sk_clone_lock+0x14/0x283 [<ffffffff812aaf3a>] inet_csk_clone_lock+0xf/0x7b [<ffffffff8129a893>] netlink_broadcast+0x14/0x16 [<ffffffff812c1573>] tcp_create_openreq_child+0x1b/0x4c3 [<ffffffff812c033e>] tcp_v4_syn_recv_sock+0x38/0x25d [<ffffffff812c13e4>] tcp_check_req+0x25c/0x3d0 [<ffffffff812bf87a>] tcp_v4_do_rcv+0x287/0x40e [<ffffffff812a08a7>] ip_route_input_noref+0x843/0xa55 [<ffffffff812bfeca>] tcp_v4_rcv+0x4c9/0x725 [<ffffffff812a26f4>] ip_local_deliver_finish+0xe9/0x154 [<ffffffff8127a927>] __netif_receive_skb+0x4b2/0x514 [<ffffffff8127aa77>] process_backlog+0xee/0x1c5 [<ffffffff8127c949>] net_rx_action+0xa7/0x200 [<ffffffff81209d86>] add_interrupt_randomness+0x39/0x157 But there are many more, resulting in the machine going OOM after some days. From looking at the TPROXY code, and with help from Florian, I see that the memory leak is introduced in tcp_v4_early_demux(): void tcp_v4_early_demux(struct sk_buff *skb) { /* ... */ iph = ip_hdr(skb); th = tcp_hdr(skb); if (th->doff < sizeof(struct tcphdr) / 4) return; sk = __inet_lookup_established(dev_net(skb->dev), &tcp_hashinfo, iph->saddr, th->source, iph->daddr, ntohs(th->dest), skb->skb_iif); if (sk) { skb->sk = sk; where the socket is assigned unconditionally to skb->sk, also bumping the refcnt on it. This is problematic, because in our case the skb has already a socket assigned in the TPROXY target. This then results in the leak I see. The very same issue seems to be with IPv6, but haven't tested. Reviewed-by: Florian Westphal <fw@strlen.de> Signed-off-by: Holger Eitzenberger <holger@eitzenberger.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06fib_frontend: fix possible NULL pointer dereferenceOliver Hartkopp
[ Upstream commit a0065f266a9b5d51575535a25c15ccbeed9a9966 ] The two commits 0115e8e30d (net: remove delay at device dismantle) and 748e2d9396a (net: reinstate rtnl in call_netdevice_notifiers()) silently removed a NULL pointer check for in_dev since Linux 3.7. This patch re-introduces this check as it causes crashing the kernel when setting small mtu values on non-ip capable netdevices. Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06net/vxlan: Share RX skb de-marking and checksum checks with ovsOr Gerlitz
[ Upstream commit d0bc65557ad09a57b4db176e9e3ccddb26971453 ] Make sure the practice set by commit 0afb166 "vxlan: Add capability of Rx checksum offload for inner packet" is applied when the skb goes through the portion of the RX code which is shared between vxlan netdevices and ovs vxlan port instances. Cc: Joseph Gasparakis <joseph.gasparakis@intel.com> Cc: Pravin B Shelar <pshelar@nicira.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ip_tunnel: clear IPCB in ip_tunnel_xmit() in case dst_link_failure() is calledDuan Jiong
[ Upstream commit 11c21a307d79ea5f6b6fc0d3dfdeda271e5e65f6 ] commit a622260254ee48("ip_tunnel: fix kernel panic with icmp_dest_unreach") clear IPCB in ip_tunnel_xmit() , or else skb->cb[] may contain garbage from GSO segmentation layer. But commit 0e6fbc5b6c621("ip_tunnels: extend iptunnel_xmit()") refactor codes, and it clear IPCB behind the dst_link_failure(). So clear IPCB in ip_tunnel_xmit() just like commti a622260254ee48("ip_tunnel: fix kernel panic with icmp_dest_unreach"). Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06s390/bpf,jit: fix 32 bit divisions, use unsigned divide instructionsHeiko Carstens
[ Upstream commit 3af57f78c38131b7a66e2b01e06fdacae01992a3 ] The s390 bpf jit compiler emits the signed divide instructions "dr" and "d" for unsigned divisions. This can cause problems: the dividend will be zero extended to a 64 bit value and the divisor is the 32 bit signed value as specified A or X accumulator, even though A and X are supposed to be treated as unsigned values. The divide instrunctions will generate an exception if the result cannot be expressed with a 32 bit signed value. This is the case if e.g. the dividend is 0xffffffff and the divisor either 1 or also 0xffffffff (signed: -1). To avoid all these issues simply use unsigned divide instructions. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06bpf: do not use reciprocal divideEric Dumazet
[ Upstream commit aee636c4809fa54848ff07a899b326eb1f9987a2 ] At first Jakub Zawadzki noticed that some divisions by reciprocal_divide were not correct. (off by one in some cases) http://www.wireshark.org/~darkjames/reciprocal-buggy.c He could also show this with BPF: http://www.wireshark.org/~darkjames/set-and-dump-filter-k-bug.c The reciprocal divide in linux kernel is not generic enough, lets remove its use in BPF, as it is not worth the pain with current cpus. Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Jakub Zawadzki <darkjames-ws@darkjames.pl> Cc: Mircea Gherzan <mgherzan@gmail.com> Cc: Daniel Borkmann <dxchgb@gmail.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Cc: Matt Evans <matt@ozlabs.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06tcp: metrics: Avoid duplicate entries with the same destination-IPChristoph Paasch
[ Upstream commit 77f99ad16a07aa062c2d30fae57b1fee456f6ef6 ] Because the tcp-metrics is an RCU-list, it may be that two soft-interrupts are inside __tcp_get_metrics() for the same destination-IP at the same time. If this destination-IP is not yet part of the tcp-metrics, both soft-interrupts will end up in tcpm_new and create a new entry for this IP. So, we will have two tcp-metrics with the same destination-IP in the list. This patch checks twice __tcp_get_metrics(). First without holding the lock, then while holding the lock. The second one is there to confirm that the entry has not been added by another soft-irq while waiting for the spin-lock. Fixes: 51c5d0c4b169b (tcp: Maintain dynamic metrics in local cache.) Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06net: rds: fix per-cpu helper usageGerald Schaefer
[ Upstream commit c196403b79aa241c3fefb3ee5bb328aa7c5cc860 ] commit ae4b46e9d "net: rds: use this_cpu_* per-cpu helper" broke per-cpu handling for rds. chpfirst is the result of __this_cpu_read(), so it is an absolute pointer and not __percpu. Therefore, __this_cpu_write() should not operate on chpfirst, but rather on cache->percpu->first, just like __this_cpu_read() did before. Signed-off-byd Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06net,via-rhine: Fix tx_timeout handlingRichard Weinberger
[ Upstream commit a926592f5e4e900f3fa903298c4619a131e60963 ] rhine_reset_task() misses to disable the tx scheduler upon reset, this can lead to a crash if work is still scheduled while we're resetting the tx queue. Fixes: [ 93.591707] BUG: unable to handle kernel NULL pointer dereference at 0000004c [ 93.595514] IP: [<c119d10d>] rhine_napipoll+0x491/0x6 Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06net: avoid reference counter overflows on fib_rules in multicast forwardingHannes Frederic Sowa
[ Upstream commit 95f4a45de1a0f172b35451fc52283290adb21f6e ] Bob Falken reported that after 4G packets, multicast forwarding stopped working. This was because of a rule reference counter overflow which freed the rule as soon as the overflow happend. This patch solves this by adding the FIB_LOOKUP_NOREF flag to fib_rules_lookup calls. This is safe even from non-rcu locked sections as in this case the flag only implies not taking a reference to the rule, which we don't need at all. Rules only hold references to the namespace, which are guaranteed to be available during the call of the non-rcu protected function reg_vif_xmit because of the interface reference which itself holds a reference to the net namespace. Fixes: f0ad0860d01e47 ("ipv4: ipmr: support multiple tables") Fixes: d1db275dd3f6e4 ("ipv6: ip6mr: support multiple tables") Reported-by: Bob Falken <NetFestivalHaveFun@gmx.com> Cc: Patrick McHardy <kaber@trash.net> Cc: Thomas Graf <tgraf@suug.ch> Cc: Julian Anastasov <ja@ssi.bg> Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ieee802154: Fix memory leak in ieee802154_add_iface()Christian Engelmayer
[ Upstream commit 267d29a69c6af39445f36102a832b25ed483f299 ] Fix a memory leak in the ieee802154_add_iface() error handling path. Detected by Coverity: CID 710490. Signed-off-by: Christian Engelmayer <cengelma@gmx.at> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06net: usbnet: fix SG initialisationBjørn Mork
[ Upstream commit fdc3452cd2c7b2bfe0f378f92123f4f9a98fa2bd ] Commit 60e453a940ac ("USBNET: fix handling padding packet") added an extra SG entry in case padding is necessary, but failed to update the initialisation of the list. This can cause list traversal to fall off the end of the list, resulting in an oops. Fixes: 60e453a940ac ("USBNET: fix handling padding packet") Reported-by: Thomas Kear <thomas@kear.co.nz> Cc: Ming Lei <ming.lei@canonical.com> Signed-off-by: Bjørn Mork <bjorn@mork.no> Tested-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06bnx2x: fix DMA unmapping of TSO split BDsMichal Schmidt
[ Upstream commit 95e92fd40c967c363ad66b2fd1ce4dcd68132e54 ] bnx2x triggers warnings with CONFIG_DMA_API_DEBUG=y: WARNING: CPU: 0 PID: 2253 at lib/dma-debug.c:887 check_unmap+0xf8/0x920() bnx2x 0000:28:00.0: DMA-API: device driver frees DMA memory with different size [device address=0x00000000da2b389e] [map size=1490 bytes] [unmap size=66 bytes] The reason is that bnx2x splits a TSO BD into two BDs (headers + data) using one DMA mapping for both, but it uses only the length of the first BD when unmapping. This patch fixes the bug by unmapping the whole length of the two BDs. Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Dmitry Kravkov <dmitry@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06i2c: piix4: Add support for AMD ML and CZ SMBus changesShane Huang
commit 032f708bc4f6da868ec49dac48ddf3670d8035d3 upstream. The locations of SMBus register base address and enablement bit are changed from AMD ML, which need this patch to be supported. Signed-off-by: Shane Huang <shane.huang@amd.com> Reviewed-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06i2c: mv64xxx: Document the newly introduced Armada XP A0 compatibleGregory CLEMENT
commit f8b94beb7e6a374cb0de531b72377c49857b35ca upstream. The first variants of Armada XP SoCs (A0 stepping) have issues related to the i2c controller which prevent to use the offload mechanism and lead to a kernel hang during boot. The commit introduces a new the compatible string marvell,mv78230-a0-i2c for the i2c controller. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> cc: devicetree@vger.kernel.org Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support) Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCsGregory CLEMENT
commit 6cf70ae928bae17077efc0d528dec49bc380438b upstream. The first variants of Armada XP SoCs (A0 stepping) have issues related to the i2c controller which prevent to use the offload mechanism and lead to a kernel hang during boot. The commit introduces a new the compatible string marvell,mv78230-a0-i2c for the i2c controller. When this compatible string is used the driver disables the offload mechanism and the kernel no more hangs on these SoCs. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reported-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support) Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 boardGregory CLEMENT
commit 85e618a1be2b2092318178d1d66bdad49cbbeeeb upstream. The first variants of Armada XP SoCs (A0 stepping) have issues related to the i2c controller which prevent to use the offload mechanism and lead to a kernel hang during boot. This commit add quirk in the mvebu platform code to check the SoC version and then update the compatible string for the i2c controller according to the revision of the SoC. Currently only some OpenBlocks AX3-4 boards are known to use an A0 revision so the check is done only for these boards. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support) Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ARM: mvebu: Add support to get the ID and the revision of a SoCGregory CLEMENT
commit af8d1c63afcbf36eea06789c92e22d4af118d2fb upstream. All the mvebu SoCs have information related to their variant and revision that can be read from the PCI control register. This patch adds support for Armada XP and Armada 370. This reading of the revision and the ID are done before the PCI initialization to avoid any conflicts. Once these data are retrieved, the resources are freed to let the PCI subsystem use it. Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support) Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06hp_accel: Add a new PnP ID HPQ6007 for new HP laptopsTakashi Iwai
commit b0ad4ff35d479a46a3b995a299db9aeb097acfce upstream. The DriveGuard chips on the new HP laptops are with a new PnP ID "HPQ6007". It should be compatible with older chips. Acked-by: Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06zram: fix race between reset and flushing pending workMinchan Kim
commit da4a04126baa3be03bc566d4a2ee0944c5e783d0 upstream. Dan and Sergey reported that there is a racy between reset and flushing of pending work so that it could make oops by freeing zram->meta in reset while zram_slot_free can access zram->meta if new request is adding during the race window. This patch moves flush after taking init_lock so it prevents new request so that it closes the race. Signed-off-by: Minchan Kim <minchan@kernel.org> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Nitin Gupta <ngupta@vflare.org> Cc: Jerome Marchand <jmarchan@redhat.com> Tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06bcache: Data corruption fixKent Overstreet
commit ef71ec00002d92a08eb27e9d036e3d48835b6597 upstream. The code that handles overlapping extents that we've just read back in from disk was depending on the behaviour of the code that handles overlapping extents as we're inserting into a btree node in the case of an insert that forced an existing extent to be split: on insert, if we had to split we'd also insert a new extent to represent the top part of the old extent - and then that new extent would get written out. The code that read the extents back in thus not bother with splitting extents - if it saw an extent that ovelapped in the middle of an older extent, it would trim the old extent to only represent the bottom part, assuming that the original insert would've inserted a new extent to represent the top part. I still haven't figured out _how_ it can happen, but I'm now pretty convinced (and testing has confirmed) that there's some kind of an obscure corner case (probably involving extent merging, and multiple overwrites in different sets) that breaks this. The fix is to change the mergesort fixup code to split extents itself when required. Signed-off-by: Kent Overstreet <kmo@daterainc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06vfs: Is mounted should be testing mnt_ns for NULL or error.Eric W. Biederman
commit 260a459d2e39761fbd39803497205ce1690bc7b1 upstream. A bug was introduced with the is_mounted helper function in commit f7a99c5b7c8bd3d3f533c8b38274e33f3da9096e Author: Al Viro <viro@zeniv.linux.org.uk> Date: Sat Jun 9 00:59:08 2012 -0400 get rid of ->mnt_longterm it's enough to set ->mnt_ns of internal vfsmounts to something distinct from all struct mnt_namespace out there; then we can just use the check for ->mnt_ns != NULL in the fast path of mntput_no_expire() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> The intent was to test if the real_mount(vfsmount)->mnt_ns was NULL_OR_ERR but the code is actually testing real_mount(vfsmount) and always returning true. The result is d_absolute_path returning paths it should be hiding. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06vfs: Remove second variable named error in __dentry_pathEric W. Biederman
commit a8323da0366d3398eda62741d2ac1130c8a172ed upstream. In commit 232d2d60aa5469bb097f55728f65146bd49c1d25 Author: Waiman Long <Waiman.Long@hp.com> Date: Mon Sep 9 12:18:13 2013 -0400 dcache: Translating dentry into pathname without taking rename_lock The __dentry_path locking was changed and the variable error was intended to be moved outside of the loop. Unfortunately the inner declaration of error was not removed. Resulting in a version of __dentry_path that will never return an error. Remove the problematic inner declaration of error and allow __dentry_path to return errors once again. Cc: Waiman Long <Waiman.Long@hp.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ext4: avoid clearing beyond i_blocks when truncating an inline data fileTheodore Ts'o
commit 09c455aaa8f47a94d5bafaa23d58365768210507 upstream. A missing cast means that when we are truncating a file which is less than 60 bytes, we don't clear the correct area of memory, and in fact we can end up truncating the next inode in the inode table, or worse yet, some other kernel data structure. Addresses-Coverity-Id: #751987 Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06libata: disable LPM for some WD SATA-I devicesTejun Heo
commit ecd75ad514d73efc1bbcc5f10a13566c3ace5f53 upstream. For some reason, some early WD drives spin up and down drives erratically when the link is put into slumber mode which can reduce the life expectancy of the device significantly. Unfortunately, we don't have full list of devices and given the nature of the issue it'd be better to err on the side of false positives than the other way around. Let's disable LPM on all WD devices which match one of the known problematic model prefixes and are SATA-I. As horkage list doesn't support matching SATA capabilities, this is implemented as two horkages - WD_BROKEN_LPM and NOLPM. The former is set for the known prefixes and sets the latter if the matched device is SATA-I. Note that this isn't optimal as this disables all LPM operations and partial link power state reportedly works fine on these; however, the way LPM is implemented in libata makes it difficult to precisely map libata LPM setting to specific link power state. Well, these devices are already fairly outdated. Let's just disable whole LPM for now. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-and-tested-by: Nikos Barkas <levelwol@gmail.com> Reported-and-tested-by: Ioannis Barkas <risc4all@yahoo.com> References: https://bugzilla.kernel.org/show_bug.cgi?id=57211 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ARM: mvebu: update the SATA compatible string for Armada 370/XPSimon Guinot
commit a96cc303e42ad7830dde929aad0046e448a05505 upstream. This patch updates the Armada 370/XP SATA node with the new compatible string "marvell,armada-370-sata". Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Lior Amsalem <alior@marvell.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ata: sata_mv: fix disk hotplug for Armada 370/XP SoCsLior Amsalem
commit 9013d64e661fc2a37a1742670202171c27fef4b5 upstream. On Armada 370/XP SoCs, once a disk is removed from a SATA port, then the re-plug events are not detected by the sata_mv driver. This patch fixes the issue by updating the PHY speed in the LP_PHY_CTL register (0x58) according to the SControl speed. Note that this fix is only applied if the compatible string "marvell,armada-370-sata" is found in the SATA DT node. Fixes: 9ae6f740b49f ("arm: mach-mvebu: add support for Armada 370 and Armada XP with DT") Signed-off-by: Lior Amsalem <alior@marvell.com> Signed-off-by: Nadav Haklai <nadavh@marvell.com> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ata: sata_mv: introduce compatible string "marvell, armada-370-sata"Simon Guinot
commit b1f5c73bd5a4752efb7d7af019034044b08aafe9 upstream. The sata_mv driver supports the SATA IP found in several Marvell SoCs. As some new SATA registers have been introduced with the Armada 370/XP SoCs, a way to identify them is needed. This patch introduces a new compatible string for the SATA IP found in Armada 370/XP SoCs. Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Lior Amsalem <alior@marvell.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06tpm/tpm_ppi: Do not compare strcmp(a,b) == -1Peter Huewe
commit 747d35bd9bb4ae6bd74b19baa5bbe32f3e0cee11 upstream. Depending on the implementation strcmp might return the difference between two strings not only -1,0,1 consequently if (strcmp (a,b) == -1) might lead to taking the wrong branch -> compare with < 0 instead, which in any case is more canonical. Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06tpm/tpm_i2c_stm_st33: Check return code of get_burstcountPeter Huewe
commit 85c5e0d451125c6ddb78663972e40af810b83644 upstream. The 'get_burstcount' function can in some circumstances 'return -EBUSY' which in tpm_stm_i2c_send is stored in an 'u32 burstcnt' thus converting the signed value into an unsigned value, resulting in 'burstcnt' being huge. Changing the type to u32 only does not solve the problem as the signed value is converted to an unsigned in I2C_WRITE_DATA, resulting in the same effect. Thus -> Change type of burstcnt to u32 (the return type of get_burstcount) -> Add a check for the return value of 'get_burstcount' and propagate a potential error. This makes also sense in the 'I2C_READ_DATA' case, where the there is no signed/unsigned conversion. found by coverity Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ALSA: hda - Fix silent output on MacBook Air 1,1Adrien Vergé
commit e7729a415315fcd9516912050d85d5aaebcededc upstream. Similarly to other Apple products, MBA 1,1 needs a specific quirk. Pin 0x18 must be set to VREF_50 to have sound output. This was no longer done since commit 1a97b7f, resulting in a mute built-in speaker. This patch corrects the regression by creating a fixup for the MBA 1,1. Fixes: 1a97b7f22774 ("ALSA: hda/realtek - Remove the last static quirks for ALC882") Tested-by: Adrien Vergé <adrienverge@gmail.com> Signed-off-by: Adrien Vergé <adrienverge@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ALSA: bits vs bytes bug in snd_card_create()Dan Carpenter
commit 4c3773eda49c872a3034382f8ec3080002e715bf upstream. The test here is intended intended to prevent shift wrapping bugs when we do "1U << idx2". We should consider the number of bits in a u32 instead of the number of bytes. [fix another chunk similarly by tiwai] Fixes: 7bb2491b35a2 ('ALSA: Add kconfig to specify the max card numbers') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ALSA: Enable CONFIG_ZONE_DMA for smaller PCI DMA masksTakashi Iwai
commit 80ab8eae70e51d578ebbeb228e0f7a562471b8b7 upstream. The PCI devices with DMA masks smaller than 32bit should enable CONFIG_ZONE_DMA. Since the recent change of page allocator, page allocations via dma_alloc_coherent() with the limited DMA mask bits may fail more frequently, ended up with no available buffers, when CONFIG_ZONE_DMA isn't enabled. With CONFIG_ZONE_DMA, the system has much more chance to obtain such pages. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68221 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ALSA: hda - Don't create duplicated ctls for loopback pathsTakashi Iwai
commit 43a8e50a46a4e1dd1451e4a4ffa1f7695fb7d287 upstream. AD1986A mic pins (0x1d and 0x1f) share the same widget for controlling the loopback volume/mute, but the generic parser didn't check it. This ended up with the duplicated controls for the same effect. This patch adds the check of the duplication for avoiding it. After this fix, there will be only one control although it affects both paths; this remaining issue should be fixed later in a different patch. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ALSA: hda - Correct AD1986A 3stack pin configsTakashi Iwai
commit ed0e0d0617a8dc3d8b82c6e54827f269f2247b07 upstream. The 3stack pin configs for AD1986A codec had incorrect values that resulted in broken mic and line-in. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ALSA: rme9652: fix a missing comma in channel_map_9636_ds[]Takashi Iwai
commit 770bd4bf2e664939a9dacd3d26ec9ff7a3933210 upstream. The lack of comma leads to the wrong channel for an SPDIF channel. Unfortunately this wasn't caught by compiler because it's still a valid expression. Reported-by: Alexander Aristov <aristov.alexander@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ASoC: wm5110: Extend SYSCLK patch file for rev DCharles Keepax
commit 34354792432b6e0a3b156819a1a19716c50d3473 upstream. Latest evaluation of the the device has given some patch file additions for improved performance. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06ASoC: adau1701: Fix ADAU1701_SEROCTL_WORD_LEN_16 constantLars-Peter Clausen
commit e20970ada3f699c113fe64b04492af083d11a7d8 upstream. The driver defines ADAU1701_SEROCTL_WORD_LEN_16 as 0x10 while it should be b10, so 0x2. This patch fixes it. Reported-by: Magnus Reftel <magnus.reftel@lockless.no> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06mfd: max77686: Fix regmap resource leak on driver removeKrzysztof Kozlowski
commit 74142ffc0b52cfe6f9d2f6f34a5f3eedbfe3ce51 upstream. The regmap used by max77686 MFD driver was not freed with regmap_exit() on driver exit. This lead to leak of resources. Replace regmap_init_i2c() call in driver probe with initialization of managed register map so the regmap will be properly freed by the device management code. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>