- 13 May, 2015 7 commits
-
-
Nicolas Schichan authored
Commit 2ec459f2 upstream. When called from prom init code, bcm63xx_gpio_init() will fail as it will call gpiochip_add() which relies on a working kmalloc() to alloc the gpio_desc array and kmalloc is not useable yet at prom init time. Move bcm63xx_gpio_init() to bcm63xx_register_devices() (an arch_initcall) where kmalloc works. Fixes: 14e85c0e ("gpio: remove gpio_descs global array") Signed-off-by:
Nicolas Schichan <nschichan@freebox.fr> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: Alexandre Courbot <acourbot@nvidia.com> Patchwork: https://patchwork.linux-mips.org/patch/9530/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David S. Miller authored
[ Upstream commit a134f083 ] If we don't do that, then the poison value is left in the ->pprev backlink. This can cause crashes if we do a disconnect, followed by a connect(). Tested-by:
Linus Torvalds <torvalds@linux-foundation.org> Reported-by:
Wen Xu <hotdog3645@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ido Shamay authored
[ Upstream commit 07841f9d ] When system is out of memory, refilling of RX buffers fails while the driver continue to pass the received packets to the kernel stack. At some point, when all RX buffers deplete, driver may fall into a sleep, and not recover when memory for new RX buffers is once again availible. This is because hardware does not have valid descriptors, so no interrupt will be generated for the driver to return to work in napi context. Fix it by schedule the napi poll function from stats_task delayed workqueue, as long as the allocations fail. Signed-off-by:
Ido Shamay <idos@mellanox.com> Signed-off-by:
Amir Vadai <amirv@mellanox.com> Signed-off-by:
-
Hariprasad Shenai authored
[ Upstream commit 7f0b8a56 ] Commit 6559a7e8 ("cxgb4: Cleanup macros so they follow the same style and look consistent") introduced a regression where reading MC1 memory in adapters where MC0 isn't present or MC0 size is not equal to MC1 size caused the adapter to crash due to incorrect computation of memoffset. Fix is to read the size of MC0 instead of MC1 for offset calculation Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by:
-
Benjamin Poirier authored
[ Upstream commit 42eab005 ] By default, the number of tx queues is limited by the number of online cpus in mlx4_en_get_profile(). However, this limit no longer holds after the ethtool .set_channels method has been called. In that situation, the driver may access invalid bits of certain cpumask variables when queue_index >= nr_cpu_ids. Signed-off-by:
Benjamin Poirier <bpoirier@suse.de> Acked-by:
-
Herbert Xu authored
[ Upstream commit cb6ccf09 ] The commit 3cdaa5be ("ipv4: Don't increase PMTU with Datagram Too Big message") broke PMTU in cases where the rt_pmtu value has expired but is smaller than the new PMTU value. This obsolete rt_pmtu then prevents the new PMTU value from being installed. Fixes: 3cdaa5be ("ipv4: Don't increase PMTU with Datagram Too Big message") Reported-by:
Gerd v. Egidy <gerd.von.egidy@intra2net.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Alexei Starovoitov authored
[ Upstream commit 876a7ae6 ] ALU64_DIV instruction should be dividing 64-bit by 64-bit, whereas do_div() does 64-bit by 32-bit divide. x64 and arm64 JITs correctly implement 64 by 64 unsigned divide. llvm BPF backend emits code assuming that ALU64_DIV does 64 by 64. Fixes: 89aa0758 ("net: sock: allow eBPF programs to be attached to sockets") Reported-by:
Michael Holzheu <holzheu@linux.vnet.ibm.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Alexei Starovoitov <ast@plumgrid.com> Signed-off-by:
-
- 06 May, 2015 33 commits
-
-
Greg Kroah-Hartman authored
-
Florian Westphal authored
commit 0b67c43c upstream. We also need to save/store in forward, else br_parse_ip_options call will zero frag_max_size as well. Fixes: 93fdd47e ('bridge: Save frag_max_size between PRE_ROUTING and POST_ROUTING') Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Junjie Mao authored
commit 1c34203a upstream. It is not necessary to call device_remove_groups() when device_add_groups() fails. The group added by device_add_groups() should be removed if sysfs_create_link() fails. Fixes: fa6fdb33 ("driver core: bus_type: add dev_groups") Signed-off-by:
Junjie Mao <junjie_mao@yeah.net> Signed-off-by:
-
Linus Walleij authored
commit 7085a740 upstream. This fixes a regression from the net subsystem: After commit d52fdbb7 "smc91x: retrieve IRQ and trigger flags in a modern way" a regression would appear on some legacy platforms such as the ARM PXA Zylonite that specify IRQ resources like this: static struct resource r = { .start = X, .end = X, .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE, }; The previous code would retrieve the resource and parse the high edge setting in the SMC91x driver, a use pattern that means every driver specifying an IRQ flag from a static resource need to parse resource flags and apply them at runtime. As we switched the code to use IRQ descriptors to retrieve the the trigger type like this: irqd_get_trigger_type(irq_get_irq_data(...)); the code would work for new platforms using e.g. device tree as the backing irq descriptor would have its flags properly set, whereas this kind of oldstyle static resources at no point assign the trigger flags to the corresponding IRQ descriptor. To make the behaviour identical on modern device tree and legacy static platform data platforms, modify platform_get_irq() to assign the trigger flags to the irq descriptor when a client looks up an IRQ from static resources. Fixes: d52fdbb7 ("smc91x: retrieve IRQ and trigger flags in a modern way") Tested-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Dan Carpenter authored
commit 13f6b191 upstream. Using the indenting we can see the curly braces were obviously intended. This is a static checker fix, but my guess is that we don't read enough bytes, because we don't calculate "t_len" correctly. Fixes: f1d82698 ('memstick: use fully asynchronous request processing') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Alex Dubov <oakad@yahoo.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Nishanth Menon authored
commit f4831605 upstream. time_init invokes timer64_init (which is __init annotation) since all of these are invoked at init time, lets maintain consistency by ensuring time_init is marked appropriately as well. This fixes the following warning with CONFIG_DEBUG_SECTION_MISMATCH=y WARNING: vmlinux.o(.text+0x3bfc): Section mismatch in reference from the function time_init() to the function .init.text:timer64_init() The function time_init() references the function __init timer64_init(). This is often because time_init lacks a __init annotation or the annotation of timer64_init is wrong. Fixes: 546a3954 ("C6X: time management") Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Mark Salter <msalter@redhat.com> Signed-off-by:
-
Vutla, Lokesh authored
commit 6d7e7e02 upstream. For cases where total length of an input SGs is not same as length of the input data for encryption, omap-aes driver crashes. This happens in the case when IPsec is trying to use omap-aes driver. To avoid this, we copy all the pages from the input SG list into a contiguous buffer and prepare a single element SG list for this buffer with length as the total bytes to crypt, which is similar thing that is done in case of unaligned lengths. Fixes: 6242332f ("crypto: omap-aes - Add support for cases of unaligned lengths") Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
-
Nicolas Iooss authored
commit a3fa71c4 upstream. In struct wl18xx_acx_rx_rate_stat, rx_frames_per_rates field is an array, not a number. This means WL18XX_DEBUGFS_FWSTATS_FILE can't be used to display this field in debugfs (it would display a pointer, not the actual data). Use WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY instead. This bug has been found by adding a __printf attribute to wl1271_format_buffer. gcc complained about "format '%u' expects argument of type 'unsigned int', but argument 5 has type 'u32 *'". Fixes: c5d94169 ("wl18xx: use new fw stats structures") Signed-off-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
mancha security authored
commit 0b053c95 upstream. OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to ensure protection from dead store optimization. For the random driver and crypto drivers, calls are emitted ... $ gdb vmlinux (gdb) disassemble memzero_explicit Dump of assembler code for function memzero_explicit: 0xffffffff813a18b0 <+0>: push %rbp 0xffffffff813a18b1 <+1>: mov %rsi,%rdx 0xffffffff813a18b4 <+4>: xor %esi,%esi 0xffffffff813a18b6 <+6>: mov %rsp,%rbp 0xffffffff813a18b9 <+9>: callq 0xffffffff813a7120 <memset> 0xffffffff813a18be <+14>: pop %rbp 0xffffffff813a18bf <+15>: retq End of assembler dump. (gdb) disassemble extract_entropy [...] 0xffffffff814a5009 <+313>: mov %r12,%rdi 0xffffffff814a500c <+316>: mov $0xa,%esi 0xffffffff814a5011 <+321>: callq 0xffffffff813a18b0 <memzero_explicit> 0xffffffff814a5016 <+326>: mov -0x48(%rbp),%rax [...] ... but in case in future we might use facilities such as LTO, then OPTIMIZER_HIDE_VAR() is not sufficient to protect gcc from a possible eviction of the memset(). We have to use a compiler barrier instead. Minimal test example when we assume memzero_explicit() would *not* be a call, but would have been *inlined* instead: static inline void memzero_explicit(void *s, size_t count) { memset(s, 0, count); <foo> } int main(void) { char buff[20]; snprintf(buff, sizeof(buff) - 1, "test"); printf("%s", buff); memzero_explicit(buff, sizeof(buff)); return 0; } With <foo> := OPTIMIZER_HIDE_VAR(): (gdb) disassemble main Dump of assembler code for function main: [...] 0x0000000000400464 <+36>: callq 0x400410 <printf@plt> 0x0000000000400469 <+41>: xor %eax,%eax 0x000000000040046b <+43>: add $0x28,%rsp 0x000000000040046f <+47>: retq End of assembler dump. With <foo> := barrier(): (gdb) disassemble main Dump of assembler code for function main: [...] 0x0000000000400464 <+36>: callq 0x400410 <printf@plt> 0x0000000000400469 <+41>: movq $0x0,(%rsp) 0x0000000000400471 <+49>: movq $0x0,0x8(%rsp) 0x000000000040047a <+58>: movl $0x0,0x10(%rsp) 0x0000000000400482 <+66>: xor %eax,%eax 0x0000000000400484 <+68>: add $0x28,%rsp 0x0000000000400488 <+72>: retq End of assembler dump. As can be seen, movq, movq, movl are being emitted inlined via memset(). Reference: http://thread.gmane.org/gmane.linux.kernel.cryptoapi/13764/ Fixes: d4c5efdb ("random: add and use memzero_explicit() for clearing data") Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by:
mancha security <mancha1@zoho.com> Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
David Rientjes authored
commit 5265047a upstream. Commit 077fcf11 ("mm/thp: allocate transparent hugepages on local node") restructured alloc_hugepage_vma() with the intent of only allocating transparent hugepages locally when there was not an effective interleave mempolicy. alloc_pages_exact_node() does not limit the allocation to the single node, however, but rather prefers it. This is because __GFP_THISNODE is not set which would cause the node-local nodemask to be passed. Without it, only a nodemask that prefers the local node is passed. Fix this by passing __GFP_THISNODE and falling back to small pages when the allocation fails. Commit 9f1b868a ("mm: thp: khugepaged: add policy for finding target node") suffers from a similar problem for khugepaged, which is also fixed. Fixes: 077fcf11 ("mm/thp: allocate transparent hugepages on local node") Fixes: 9f1b868a ("mm: thp: khugepaged: add policy for finding target node") Signed-off-by:
David Rientjes <rientjes@google.com> Acked-by:
Vlastimil Babka <vbabka@suse.cz> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Mel Gorman <mgorman@suse.de> Cc: Pravin Shelar <pshelar@nicira.com> Cc: Jarno Rajahalme <jrajahalme@nicira.com> Cc: Li Zefan <lizefan@huawei.com> Cc: Greg Thelen <gthelen@google.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
-
Daniel Borkmann authored
commit 80f1d68c upstream. I noticed that a helper function with argument type ARG_ANYTHING does not need to have an initialized value (register). This can worst case lead to unintented stack memory leakage in future helper functions if they are not carefully designed, or unintended application behaviour in case the application developer was not careful enough to match a correct helper function signature in the API. The underlying issue is that ARG_ANYTHING should actually be split into two different semantics: 1) ARG_DONTCARE for function arguments that the helper function does not care about (in other words: the default for unused function arguments), and 2) ARG_ANYTHING that is an argument actually being used by a helper function and *guaranteed* to be an initialized register. The current risk is low: ARG_ANYTHING is only used for the 'flags' argument (r4) in bpf_map_update_elem() that internally does strict checking. Fixes: 17a52670 ("bpf: verifier (add verifier core)") Signed-off-by:
-
Johannes Berg authored
commit a73f8e21 upstream. Louis reported that a static checker was complaining that the 'dst' variable was set (multiple times) but not used. This is due to a previous commit having removed the usage (apparently erroneously), so add it back. Fixes: a344d677 ("mac80211: allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDR") Reported-by:
Louis Langholtz <lou_langholtz@me.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Sabrina Dubroca authored
commit 08e83316 upstream. There is a race condition between e1000_change_mtu's cleanups and netpoll, when we change the MTU across jumbo size: Changing MTU frees all the rx buffers: e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings -> e1000_clean_rx_ring Then, close to the end of e1000_change_mtu: pr_info -> ... -> netpoll_poll_dev -> e1000_clean -> e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag And when we come back to do the rest of the MTU change: e1000_up -> e1000_configure -> e1000_configure_rx -> e1000_alloc_jumbo_rx_buffers alloc_jumbo finds the buffers already != NULL, since data (shared with page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage, or at least not what is expected when in jumbo state. This results in an unusable adapter (packets don't get through), and a NULL pointer dereference on the next call to e1000_clean_rx_ring (other mtu change, link down, shutdown): BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff81194d6e>] put_compound_page+0x7e/0x330 [...] Call Trace: [<ffffffff81195445>] put_page+0x55/0x60 [<ffffffff815d9f44>] e1000_clean_rx_ring+0x134/0x200 [<ffffffff815da055>] e1000_clean_all_rx_rings+0x45/0x60 [<ffffffff815df5e0>] e1000_down+0x1c0/0x1d0 [<ffffffff811e2260>] ? deactivate_slab+0x7f0/0x840 [<ffffffff815e21bc>] e1000_change_mtu+0xdc/0x170 [<ffffffff81647050>] dev_set_mtu+0xa0/0x140 [<ffffffff81664218>] do_setlink+0x218/0xac0 [<ffffffff814459e9>] ? nla_parse+0xb9/0x120 [<ffffffff816652d0>] rtnl_newlink+0x6d0/0x890 [<ffffffff8104f000>] ? kvm_clock_read+0x20/0x40 [<ffffffff810a2068>] ? sched_clock_cpu+0xa8/0x100 [<ffffffff81663802>] rtnetlink_rcv_msg+0x92/0x260 By setting the allocator to a dummy version, netpoll can't mess up our rx buffers. The allocator is set back to a sane value in e1000_configure_rx. Fixes: edbbb3ca ("e1000: implement jumbo receive with partial descriptors") Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Juri Lelli authored
commit 4cd57f97 upstream. dl_task_timer() may fire on a different rq from where a task was removed after throttling. Since the call path is: dl_task_timer() -> enqueue_task_dl() -> enqueue_dl_entity() -> replenish_dl_entity() and replenish_dl_entity() uses dl_se's rq, we can't use current's rq in dl_task_timer(), but we need to lock the task's previous one. Tested-by:
Wanpeng Li <wanpeng.li@linux.intel.com> Signed-off-by:
Juri Lelli <juri.lelli@arm.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Kirill Tkhai <ktkhai@parallels.com> Cc: Juri Lelli <juri.lelli@gmail.com> Fixes: 3960c8c0 ("sched: Make dl_task_time() use task_rq_lock()") Link: http://lkml.kernel.org/r/1427792017-7356-1-git-send-email-juri.lelli@arm.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Anna Schumaker authored
commit 7c61f0d3 upstream. d4b18c3e (pnfs: remove GETDEVICELIST implementation) removed the GETDEVICELIST operation from the NFS client, but left a "hole" in the nfs4_procedures array. This caused /proc/self/mountstats to report an operation named "51" where GETDEVICELIST used to be. This patch adds a stub to fix mountstats. Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Fixes: d4b18c3e (pnfs: remove GETDEVICELIST implementation) Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Peng Tao authored
commit 05f54903 upstream. For flexfiles driver, we might choose to read from mirror index other than 0 while mirror_count is always 1 for read. Reported-by:
Jean Spector <jean@primarydata.com> Cc: Weston Andros Adamson <dros@primarydata.com> Signed-off-by:
Peng Tao <tao.peng@primarydata.com> Signed-off-by:
-
Peng Tao authored
commit 1ccbad9f upstream. For direct read that has IO size larger than rsize, we'll split it into several READ requests and nfs_direct_good_bytes() would count completed bytes incorrectly by eating last zero count reply. Fix it by handling mirror and non-mirror cases differently such that we only count mirrored writes differently. This fixes 5fadeb47("nfs: count DIO good bytes correctly with mirroring"). Reported-by:
-
Jeff Layton authored
commit 5d05e54a upstream. Chuck pointed out a problem that crept in with commit 6ffa30d3 (nfs: don't call blocking operations while !TASK_RUNNING). Linux counts tasks in uninterruptible sleep against the load average, so this caused the system's load average to be pinned at at least 1 when there was a NFSv4.1+ mount active. Not a huge problem, but it's probably worth fixing before we get too many complaints about it. This patch converts the code back to use TASK_INTERRUPTIBLE sleep, simply has it flush any signals on each loop iteration. In practice no one should really be signalling this thread at all, so I think this is reasonably safe. With this change, there's also no need to game the hung task watchdog so we can also convert the schedule_timeout call back to a normal schedule. Reported-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Jeff Layton <jeff.layton@primarydata.com> Tested-by:
-
Giuseppe Cantavenera authored
commit bb7ffbf2 upstream. nfsd triggered a BUG_ON in net_generic(...) when rpc_pipefs_event(...) in fs/nfsd/nfs4recover.c was called before assigning ntfsd_net_id. The following was observed on a MIPS 32-core processor: kernel: Call Trace: kernel: [<ffffffffc00bc5e4>] rpc_pipefs_event+0x7c/0x158 [nfsd] kernel: [<ffffffff8017a2a0>] notifier_call_chain+0x70/0xb8 kernel: [<ffffffff8017a4e4>] __blocking_notifier_call_chain+0x4c/0x70 kernel: [<ffffffff8053aff8>] rpc_fill_super+0xf8/0x1a0 kernel: [<ffffffff8022204c>] mount_ns+0xb4/0xf0 kernel: [<ffffffff80222b48>] mount_fs+0x50/0x1f8 kernel: [<ffffffff8023dc00>] vfs_kern_mount+0x58/0xf0 kernel: [<ffffffff802404ac>] do_mount+0x27c/0xa28 kernel: [<ffffffff80240cf0>] SyS_mount+0x98/0xe8 kernel: [<ffffffff80135d24>] handle_sys64+0x44/0x68 kernel: kernel: Code: 0040f809 00000000 2e020001 <00020336> 3c12c00d 3c02801a de100000 6442eb98 0040f809 kernel: ---[ end trace 7471374335809536 ]--- Fixed this behaviour by calling register_pernet_subsys(&nfsd_net_ops) before registering rpc_pipefs_event(...) with the notifier chain. Signed-off-by:
Giuseppe Cantavenera <giuseppe.cantavenera.ext@nokia.com> Signed-off-by:
Lorenzo Restelli <lorenzo.restelli.ext@nokia.com> Reviewed-by:
Kinlong Mee <kinglongmee@gmail.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Mark Salter authored
commit 135dd002 upstream. Commit f895b252 ("sunrpc: eliminate RPC_DEBUG") introduced use of IS_ENABLED() in a uapi header which leads to a build failure for userspace apps trying to use <linux/nfsd/debug.h>: linux/nfsd/debug.h:18:15: error: missing binary operator before token "(" #if IS_ENABLED(CONFIG_SUNRPC_DEBUG) ^ Since this was only used to define NFSD_DEBUG if CONFIG_SUNRPC_DEBUG is enabled, replace instances of NFSD_DEBUG with CONFIG_SUNRPC_DEBUG. Fixes: f895b252 "sunrpc: eliminate RPC_DEBUG" Signed-off-by:
Jeff Layton <jlayton@primarydata.com> Signed-off-by:
-
J. Bruce Fields authored
commit 980608fb upstream. If the client uses a special stateid then we'll pass a NULL file to vfs_llseek. Fixes: 24bab491 " NFSD: Implement SEEK" Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Reported-by:
Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
J. Bruce Fields authored
commit 6e4891dc upstream. In the case we already have a struct file (derived from a stateid), we still need to do permission-checking; otherwise an unauthorized user could gain access to a file by sniffing or guessing somebody else's stateid. Fixes: dc97618d "nfsd4: separate splice and readv cases" Signed-off-by:
-
J. Bruce Fields authored
commit 5ba4a25a upstream. vfs_fallocate will hit a NULL dereference if the client tries an ALLOCATE or DEALLOCATE with a special stateid. Fix that. (We also depend on the open to have broken any conflicting leases or delegations for us.) (If it turns out we need to allow special stateid's then we could do a temporary open here in the special-stateid case, as we do for read and write. For now I'm assuming it's not necessary.) Fixes: 95d871f0 "nfsd: Add ALLOCATE support" Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Nicolas Iooss authored
commit 3708f842 upstream. This reverts commit 5a254d08. Since commit 5a254d08 ("nfs: replace nfs_add_stats with nfs_inc_stats when add one"), nfs_readpage and nfs_do_writepage use nfs_inc_stats to increment NFSIOS_READPAGES and NFSIOS_WRITEPAGES instead of nfs_add_stats. However nfs_inc_stats does not do the same thing as nfs_add_stats with value 1 because these functions work on distinct stats: nfs_inc_stats increments stats from "enum nfs_stat_eventcounters" (in server->io_stats->events) and nfs_add_stats those from "enum nfs_stat_bytecounters" (in server->io_stats->bytes). Signed-off-by:
-
Al Viro authored
commit 3cab989a upstream. Calling unlazy_walk() in walk_component() and do_last() when we find a symlink that needs to be followed doesn't acquire a reference to vfsmount. That's fine when the symlink is on the same vfsmount as the parent directory (which is almost always the case), but it's not always true - one _can_ manage to bind a symlink on top of something. And in such cases we end up with excessive mntput(). Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Dmitry Torokhov authored
commit 9535c475 upstream. The hardware, according to the specs, is limited to 256 byte transfers, and current driver has no protections in case users attempt to do larger transfers. The code will just stomp over status register and mayhem ensues. Let's split larger transfers into digestable chunks. Doing this allows Atmel MXT driver on Pixel 1 function properly (it hasn't since commit 9d8dc3e5 "Input: atmel_mxt_ts - implement T44 message handling" which tries to consume multiple touchscreen/touchpad reports in a single transaction). Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Imre Deak authored
commit b5f1c97f upstream. Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across suspend/resume, so fix this. This was introduced in commit ddeea5b0 Author: Imre Deak <imre.deak@intel.com> Date: Mon May 5 15:19:56 2014 +0300 drm/i915: vlv: add runtime PM support I noticed this only by reading the code. To my knowledge it shouldn't cause any real problems at the moment, since the power well backing this register remains on across a runtime s/r. This may change once system-wide s0ix functionality is enabled in the kernel. v2: - resend after a missing git add -u :/ Signed-off-by:
Imre Deak <imre.deak@intel.com> Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Laurent Pinchart authored
commit a5241289 upstream. The EDID read code waits for the read completion interrupt to occur using wait_event_interruptible(). The condition passed to the macro reads I2C registers. This results in sleeping with the task state set to TASK_INTERRUPTIBLE, triggering a WARN_ON() introduced in commit 8eb23b9f ("sched: Debug nested sleeps"). Fix this by reworking the EDID read code. Instead of checking whether the read is complete through I2C reads, handle the interrupt registers in the interrupt handler and update a new edid_read flag accordingly. As a side effect both the IRQ and polling code paths now process the interrupt sources through the same code path, simplifying the code. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
commit 2e96206c upstream. The DDC error interrupt bit is located in REG_INT1, not REG_INT0. Update both the interrupt wait code and the interrupt sources reset code accordingly. Signed-off-by:
-
Daniel Vetter authored
commit 37ef01ab upstream. We stopped handling them in commit aaecdf61 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Nov 4 15:52:22 2014 +0100 drm/i915: Stop gathering error states for CS error interrupts but just clearing is apparently not enough: A sufficiently dead gpu left behind by firmware (*cough* coreboot *cough*) can keep the gpu in an endless loop of such interrupts, eventually leading to the nmi firing. And definitely to what looks like a machine hang. Since we don't even enable these interrupts on gen5+ let's do the same on earlier platforms. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93171Tested-by:
Mono <mono-for-kernel-org@donderklumpen.de> Tested-by: info@gluglug.org.uk Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Krzysztof Kozlowski authored
commit 1c363c7c upstream. After adding display power domain for Exynos5250 in commit 2d2c9a8d ("ARM: dts: add display power domain for exynos5250") the display on Chromebook Snow and others stopped working after boot. The reason for this suggested Andrzej Hajda: the DP clock was disabled. This clock is required by Display Port and is enabled by bootloader. However when FIMD driver probing was deferred, the display power domain was turned off. This effectively reset the value of DP clock enable register. When exynos-dp is later probed, the clock is not enabled and display is not properly configured: exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok exynos-dp 145b0000.dp-controller: unable to config video Fixes: 2d2c9a8d ("ARM: dts: add display power domain for exynos5250") Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Reported-by:
Javier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by:
Andreas Färber <afaerber@suse.de> Signed-off-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
-
Alex Deucher authored
commit fd99a094 upstream. Use the correct flags for atom. v2: handle DRM_MODE_FLAG_DBLCLK Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Mark Brown authored
commit c1c21f4e upstream. Current -next fails to link an ARM allmodconfig because drivers that use the core recovery functions can be built as modules but those functions are not exported: ERROR: "i2c_generic_gpio_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined! ERROR: "i2c_generic_scl_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined! ERROR: "i2c_recover_bus" [drivers/i2c/busses/i2c-davinci.ko] undefined! Add exports to fix this. Fixes: 5f9296ba (i2c: Add bus recovery infrastructure) Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
