- 17 May, 2015 40 commits
-
-
Naoya Horiguchi authored
[ Upstream commit 97534127 ] Commit 61f77eda ("mm/hugetlb: reduce arch dependent code around follow_huge_*") broke follow_huge_pmd() on s390, where pmd and pte layout differ and using pte_page() on a huge pmd will return wrong results. Using pmd_page() instead fixes this. All architectures that were touched by that commit have pmd_page() defined, so this should not break anything on other architectures. Fixes: 61f77eda "mm/hugetlb: reduce arch dependent code around follow_huge_*" Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Acked-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Hugh Dickins <hughd@google.com> Cc: Michal Hocko <mhocko@suse.cz>, Andrea Arcangeli <aarcange@redhat.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Acked-by:
David Rientjes <rientjes@google.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Ian Abbott authored
[ Upstream commit abe46b89 ] Reading of analog input channels by the `INSN_READ` comedi instruction is broken for all except channel 0. `pci171x_ai_insn_read()` calls `pci171x_ai_read_sample()` with the wrong value for the third parameter. It is supposed to be the current index in a channel list (which is always of length 1 in this case, so the index should be 0), but instead it is passing the actual channel number. `pci171x_ai_read_sample()` checks the channel number encoded in the raw sample value read from the hardware matches the channel number stored in the specified index of the previously set up channel list and returns `-ENODATA` if it doesn't match. Since the index should always be 0 in this case, the match will fail unless the channel number is also 0. Fix it by passing 0 as the channel index. Note that when the bug first appeared, it was `pci171x_ai_dropout()` that was called with the wrong parameter value. `pci171x_ai_dropout()` got replaced with `pci171x_ai_read_sample()` in commit 7fd2dae2 ("staging: comedi: adv_pci1710: introduce pci171x_ai_read_sample()"). Fixes: 16c7eb60 ("staging: comedi: adv_pci1710: always enable PCI171x_PARANOIDCHECK code") Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Cc: stable <stable@vger.kernel.org> # 3.16+ Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Radim Krčmář authored
[ Upstream commit 0790ec17 ] If EPT was enabled, unrestricted_guest was allowed in L1 regardless of L0. L1 triple faulted when running L2 guest that required emulation. Another side effect was 'WARN_ON_ONCE(vmx->nested.nested_run_pending)' in L0's dmesg: WARNING: CPU: 0 PID: 0 at arch/x86/kvm/vmx.c:9190 nested_vmx_vmexit+0x96e/0xb00 [kvm_intel] () Prevent this scenario by masking SECONDARY_EXEC_UNRESTRICTED_GUEST when the host doesn't have it enabled. Fixes: 78051e3b ("KVM: nVMX: Disable unrestricted mode if ept=0") Cc: stable@vger.kernel.org Tested-By:
Kashyap Chamarthy <kchamart@redhat.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Florian Westphal authored
[ Upstream commit 0b67c43c ] 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
[ Upstream commit 1c34203a ] 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
[ Upstream commit 7085a740 ] 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
[ Upstream commit 13f6b191 ] 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:
-
Nishanth Menon authored
[ Upstream commit f4831605 ] 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
[ Upstream commit 6d7e7e02 ] 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:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Nicolas Iooss authored
[ Upstream commit a3fa71c4 ] 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
[ Upstream commit 0b053c95 ] 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:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 80f1d68c ] 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:
Alexei Starovoitov <ast@plumgrid.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Sabrina Dubroca authored
[ Upstream commit 08e83316 ] 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:
-
Anna Schumaker authored
[ Upstream commit 7c61f0d3 ] 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) Cc: stable@vger.kernel.org # 3.17+ Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
J. Bruce Fields authored
[ Upstream commit 980608fb ] 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> Cc: stable@vger.kernel.org Reported-by:
Christoph Hellwig <hch@infradead.org> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
[ Upstream commit 6e4891dc ] 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. Cc: stable@vger.kernel.org Fixes: dc97618d "nfsd4: separate splice and readv cases" Signed-off-by:
-
Al Viro authored
[ Upstream commit 3cab989a ] 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(). Cc: stable@vger.kernel.org # since 2.6.39 Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Dmitry Torokhov authored
[ Upstream commit 9535c475 ] 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). Cc: stable@vger.kernel.org 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
[ Upstream commit b5f1c97f ] 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 :/ Cc: stable@vger.kernel.org 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:
-
Daniel Vetter authored
[ Upstream commit 37ef01ab ] 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 Cc: stable@vger.kernel.org Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Alex Deucher authored
[ Upstream commit fd99a094 ] Use the correct flags for atom. v2: handle DRM_MODE_FLAG_DBLCLK Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Mark Brown authored
[ Upstream commit c1c21f4e ] 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:
-
Dmitry Torokhov authored
[ Upstream commit c6cbfb91 ] master_xfer() method should return number of i2c messages transferred, but on Rockchip we were usually returning just 1, which caused trouble with users that actually check number of transferred messages vs. checking for negative error codes. Signed-off-by:
-
Rabin Vincent authored
[ Upstream commit ef99b88b ] graph_trace_open() can be called in atomic context from ftrace_dump(). Use GFP_ATOMIC for the memory allocations when that's the case, in order to avoid the following splat. BUG: sleeping function called from invalid context at mm/slab.c:2849 in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0 Backtrace: .. [<8004dc94>] (__might_sleep) from [<801371f4>] (kmem_cache_alloc_trace+0x160/0x238) r7:87800040 r6:000080d0 r5:810d16e8 r4:000080d0 [<80137094>] (kmem_cache_alloc_trace) from [<800cbd60>] (graph_trace_open+0x30/0xd0) r10:00000100 r9:809171a8 r8:00008e28 r7:810d16f0 r6:00000001 r5:810d16e8 r4:810d16f0 [<800cbd30>] (graph_trace_open) from [<800c79c4>] (trace_init_global_iter+0x50/0x9c) r8:00008e28 r7:808c853c r6:00000001 r5:810d16e8 r4:810d16f0 r3:800cbd30 [<800c7974>] (trace_init_global_iter) from [<800c7aa0>] (ftrace_dump+0x90/0x2ec) r4:810d2580 r3:00000000 [<800c7a10>] (ftrace_dump) from [<80414b2c>] (sysrq_ftrace_dump+0x1c/0x20) r10:00000100 r9:809171a8 r8:808f6e7c r7:00000001 r6:00000007 r5:0000007a r4:808d5394 [<80414b10>] (sysrq_ftrace_dump) from [<800169b8>] (return_to_handler+0x0/0x18) [<80415498>] (__handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18) r8:808c8100 r7:808c8444 r6:00000101 r5:00000010 r4:84eb3210 [<80415668>] (handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18) [<8042a760>] (pl011_int) from [<800169b8>] (return_to_handler+0x0/0x18) r10:809171bc r9:809171a8 r8:00000001 r7:00000026 r6:808c6000 r5:84f01e60 r4:8454fe00 [<8007782c>] (handle_irq_event_percpu) from [<80077b44>] (handle_irq_event+0x4c/0x6c) r10:808c7ef0 r9:87283e00 r8:00000001 r7:00000000 r6:8454fe00 r5:84f01e60 r4:84f01e00 [<80077af8>] (handle_irq_event) from [<8007aa28>] (handle_fasteoi_irq+0xf0/0x1ac) r6:808f52a4 r5:84f01e60 r4:84f01e00 r3:00000000 [<8007a938>] (handle_fasteoi_irq) from [<80076dc0>] (generic_handle_irq+0x3c/0x4c) r6:00000026 r5:00000000 r4:00000026 r3:8007a938 [<80076d84>] (generic_handle_irq) from [<80077128>] (__handle_domain_irq+0x8c/0xfc) r4:808c1e38 r3:0000002e [<8007709c>] (__handle_domain_irq) from [<800087b8>] (gic_handle_irq+0x34/0x6c) r10:80917748 r9:00000001 r8:88802100 r7:808c7ef0 r6:808c8fb0 r5:00000015 r4:8880210c r3:808c7ef0 [<80008784>] (gic_handle_irq) from [<80014044>] (__irq_svc+0x44/0x7c) Link: http://lkml.kernel.org/r/1428953721-31349-1-git-send-email-rabin@rab.in Link: http://lkml.kernel.org/r/1428957012-2319-1-git-send-email-rabin@rab.in Cc: stable@vger.kernel.org # 3.13+ Signed-off-by:
Rabin Vincent <rabin@rab.in> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Sagi Grimberg authored
[ Upstream commit a065fe6a ] This length miss-calculation may cause a silent data corruption in the DIX case and cause the device to reference unmapped area. Fixes: d77e6535 ('libiscsi, iser: Adjust data_length to include protection information') Signed-off-by:
Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Erez Shitrit authored
[ Upstream commit ca9b590c ] The current code decreases from the mss size (which is the gso_size from the kernel skb) the size of the packet headers. It shouldn't do that because the mss that comes from the stack (e.g IPoIB) includes only the tcp payload without the headers. The result is indication to the HW that each packet that the HW sends is smaller than what it could be, and too many packets will be sent for big messages. An easy way to demonstrate one more aspect of the problem is by configuring the ipoib mtu to be less than 2*hlen (2*56) and then run app sending big TCP messages. This will tell the HW to send packets with giant (negative value which under unsigned arithmetics becomes a huge positive one) length and the QP moves to SQE state. Fixes: b832be1e ('IB/mlx4: Add IPoIB LSO support') Reported-by:
Matthew Finlay <matt@mellanox.com> Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Yann Droneaud authored
[ Upstream commit 66578b0b ] In a call to ib_umem_get(), if address is 0x0 and size is already page aligned, check added in commit 8494057a ("IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic") will refuse to register a memory region that could otherwise be valid (provided vm.mmap_min_addr sysctl and mmap_low_allowed SELinux knobs allow userspace to map something at address 0x0). This patch allows back such registration: ib_umem_get() should probably don't care of the base address provided it can be pinned with get_user_pages(). There's two possible overflows, in (addr + size) and in PAGE_ALIGN(addr + size), this patch keep ensuring none of them happen while allowing to pin memory at address 0x0. Anyway, the case of size equal 0 is no more (partially) handled as 0-length memory region are disallowed by an earlier check. Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com Cc: <stable@vger.kernel.org> # 8494057a ("IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic") Cc: Shachar Raindel <raindel@mellanox.com> Cc: Jack Morgenstein <jackm@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
Yann Droneaud <ydroneaud@opteya.com> Reviewed-by:
Haggai Eran <haggaie@mellanox.com> Signed-off-by:
-
Yann Droneaud authored
[ Upstream commit 8abaae62 ] If ib_umem_get() is called with a size equal to 0 and an non-page aligned address, one page will be pinned and a 0-sized umem will be returned to the caller. This should not be allowed: it's not expected for a memory region to have a size equal to 0. This patch adds a check to explicitly refuse to register a 0-sized region. Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com Cc: <stable@vger.kernel.org> Cc: Shachar Raindel <raindel@mellanox.com> Cc: Jack Morgenstein <jackm@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Ezequiel Garcia authored
[ Upstream commit aeff0927 ] The available (i.e. not used) buffers are returned by stk1160_clear_queue(), on the stop_streaming() path. However, this is insufficient and the current buffer must be released as well. Fix it. Cc: stable@vger.kernel.org Signed-off-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Sifan Naeem authored
[ Upstream commit 80ccf4ad ] img_ir_remove() passes a pointer to the ISR function as the 2nd parameter to irq_free() instead of a pointer to the device data structure. This issue causes unloading img-ir module to fail with the below warning after building and loading img-ir as a module. WARNING: CPU: 2 PID: 155 at ../kernel/irq/manage.c:1278 __free_irq+0xb4/0x214() Trying to free already-free IRQ 58 Modules linked in: img_ir(-) CPU: 2 PID: 155 Comm: rmmod Not tainted 3.14.0 #55 ... Call Trace: ... [<8048d420>] __free_irq+0xb4/0x214 [<8048d6b4>] free_irq+0xac/0xf4 [<c009b130>] img_ir_remove+0x54/0xd4 [img_ir] [<8073ded0>] platform_drv_remove+0x30/0x54 ... Fixes: 160a8f8a ("[media] rc: img-ir: add base driver") Signed-off-by:
Sifan Naeem <sifan.naeem@imgtec.com> Cc: <stable@vger.kernel.org> # 3.15+ Acked-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
James Bottomley authored
[ Upstream commit 56cbd0cc ] mvsas is giving a General protection fault when it encounters an expander attached ATA device. Analysis of mvs_task_prep_ata() shows that the driver is assuming all ATA devices are locally attached and obtaining the phy mask by indexing the local phy table (in the HBA structure) with the phy id. Since expanders have many more phys than the HBA, this is causing the index into the HBA phy table to overflow and returning rubbish as the pointer. mvs_task_prep_ssp() instead does the phy mask using the port properties. Mirror this in mvs_task_prep_ata() to fix the panic. Reported-by:
Adam Talbot <ajtalbot1@gmail.com> Tested-by:
James Bottomley <JBottomley@Odin.com> Signed-off-by:
-
K. Y. Srinivasan authored
[ Upstream commit 40384e4b ] Correctly rollback state if the failure occurs after we have handed over the ownership of the buffer to the host. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Martin K. Petersen authored
[ Upstream commit e557990e ] 3aec2f41 introduced a merge error where we would end up check for sdkp instead of sdkp->ATO. Fix this so we register app tag capability correctly. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Cc: <stable@vger.kernel.org> # v3.17+ Reviewed-by:
-
Martin K. Petersen authored
[ Upstream commit e727c42b ] The new integrity code did not correctly unregister the profile for SD disks. Call blk_integrity_unregister() when we release a disk. Signed-off-by:
Sagi Grimberg <sagig@dev.mellanox.co.il> Tested-by:
-
Ben Collins authored
[ Upstream commit c0403ec0 ] This reverts Linux 4.1-rc1 commit 0618764c. The problem which that commit attempts to fix actually lies in the Freescale CAAM crypto driver not dm-crypt. dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto driver should internally backlog requests which arrive when the queue is full and process them later. Until the crypto hw's queue becomes full, the driver returns -EINPROGRESS. When the crypto hw's queue if full, the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is expected to backlog the request and process it when the hardware has queue space. At the point when the driver takes the request from the backlog and starts processing it, it calls the completion function with a status of -EINPROGRESS. The completion function is called (for a second time, in the case of backlogged requests) with a status/err of 0 when a request is done. Crypto drivers for hardware without hardware queueing use the helpers, crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request() and crypto_get_backlog() helpers to implement this behaviour correctly, while others implement this behaviour without these helpers (ccp, for example). dm-crypt (before the patch that needs reverting) uses this API correctly. It queues up as many requests as the hw queues will allow (i.e. as long as it gets back -EINPROGRESS from the request function). Then, when it sees at least one backlogged request (gets -EBUSY), it waits till that backlogged request is handled (completion gets called with -EINPROGRESS), and then continues. The references to af_alg_wait_for_completion() and af_alg_complete() in that commit's commit message are irrelevant because those functions only handle one request at a time, unlink dm-crypt. The problem is that the Freescale CAAM driver, which that commit describes as having being tested with, fails to implement the backlogging behaviour correctly. In cam_jr_enqueue(), if the hardware queue is full, it simply returns -EBUSY without backlogging the request. What the observed deadlock was is not described in the commit message but it is obviously the wait_for_completion() in crypto_convert() where dm-crypto would wait for the completion being called with -EINPROGRESS in the case of backlogged requests. This completion will never be completed due to the bug in the CAAM driver. Commit 0618764c incorrectly made dm-crypt wait for every request, even when the driver/hardware queues are not full, which means that dm-crypt will never see -EBUSY. This means that that commit will cause a performance regression on all crypto drivers which implement the API correctly. Revert it. Correct backlog handling should be implemented in the CAAM driver instead. Cc'ing stable purely because commit 0618764c did. If for some reason a stable@ kernel did pick up commit 0618764c it should get reverted. Signed-off-by:
Rabin Vincent <rabin.vincent@axis.com> Reviewed-by:
Horia Geanta <horia.geanta@freescale.com> Cc: stable@vger.kernel.org Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Archit Taneja authored
[ Upstream commit 0b21503d ] Currently, a RCG's M/N counter (used for fraction division) is set to either 'bypass' (counter disabled) or 'dual edge' (counter enabled) based on whether the corresponding rcg struct has a mnd field specified and a non-zero N. In the case where M and N are the same value, the M/N counter is still enabled by code even though no division takes place. Leaving the RCG in such a state can result in improper behavior. This was observed with the DSI pixel clock RCG when M and N were both set to 1. Add an additional check (M != N) to enable the M/N counter only when it's needed for fraction division. Signed-off-by:
Archit Taneja <architt@codeaurora.org> Fixes: bcd61c0f (clk: qcom: Add support for root clock generators (RCGs)) Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Stephen Boyd authored
[ Upstream commit 0bf0ff82 ] PXO is 25MHz, not 27MHz. Fix the table. Fixes: 24d8fba4 "clk: qcom: Add support for IPQ8064's global clock controller (GCC)" Signed-off-by:
Andy Gross <agross@codeaurora.org> Tested-by:
Michael Turquette <mturquette@linaro.org> Signed-off-by:
-
Thierry Reding authored
[ Upstream commit 5e43e259 ] The number of resets controls is 32 times the number of peripheral register banks rather than 32 times the number of clocks. This reduces (drastically) the number of reset controls registered from 10080 (315 clocks * 32) to 224 (6 peripheral register banks * 32). This also fixes a potential crash because trying to use any of the excess reset controls (224-10079) would have caused accesses beyond the array bounds of the peripheral register banks definition array. Cc: Peter De Schrijver <pdeschrijver@nvidia.com> Cc: Prashant Gaikwad <pgaikwad@nvidia.com> Fixes: 6d5b988e ("clk: tegra: implement a reset driver") Cc: stable@vger.kernel.org # 3.14+ Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
[ Upstream commit 3a9e9cb6 ] Commit 42773b28 ("clk: samsung: exynos4: Enable ARMCLK down feature") enabled ARMCLK down feature on all Exynos4 SoCs. Unfortunately on Exynos4210 SoC ARMCLK down feature causes a lockup when ondemand cpufreq governor is used. Fix it by limiting ARMCLK down feature to Exynos4x12 SoCs. This patch was tested on: - Exynos4210 SoC based Trats board - Exynos4210 SoC based Origen board - Exynos4412 SoC based Trats2 board - Exynos4412 SoC based Odroid-U3 board Cc: Daniel Drake <drake@endlessm.com> Cc: Tomasz Figa <t.figa@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Fixes: 42773b28 ("clk: samsung: exynos4: Enable ARMCLK down feature") Cc: <stable@vger.kernel.org> # v3.17+ Reviewed-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Gregory CLEMENT authored
[ Upstream commit 61819549 ] Level IRQ handlers and edge IRQ handler are managed by tow different sets of registers. But currently the driver uses the same mask for the both registers. It lead to issues with the following scenario: First, an IRQ is requested on a GPIO to be triggered on front. After, this an other IRQ is requested for a GPIO of the same bank but triggered on level. Then the first one will be also setup to be triggered on level. It leads to an interrupt storm. The different kind of handler are already associated with two different irq chip type. With this patch the driver uses a private mask for each one which solves this issue. It has been tested on an Armada XP based board and on an Armada 375 board. For the both boards, with this patch is applied, there is no such interrupt storm when running the previous scenario. This bug was already fixed but in a different way in the legacy version of this driver by Evgeniy Dushistov: 9ece8839 "ARM: orion: Fix for certain sequence of request_irq can cause irq storm". The fact the new version of the gpio drive could be affected had been discussed there: http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012Reported-by:
Evgeniy A. Dushistov <dushistov@mail.ru> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.7 + Signed-off-by:
-
