- 14 Mar, 2019 40 commits
-
-
Jon Hunter authored
BugLink: https://bugs.launchpad.net/bugs/1818815 commit 35deff7e upstream. The as3722 device is registered as an irqchip and the as3722-rtc interrupt is one of it's interrupt sources. When using the as3722-rtc as a wake-up device from suspend, the following is seen: PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.001 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 161.119 msecs PM: late suspend of devices complete after 1.048 msecs PM: noirq suspend of devices complete after 0.756 msecs Disabling non-boot CPUs ... CPU1: shutdown CPU2: shutdown CPU3: shutdown Entering suspend state LP1 Enabling non-boot CPUs ... CPU1 is up CPU2 is up CPU3 is up PM: noirq resume of devices complete after 0.487 msecs as3722 4-0040: Failed to read IRQ status: -16 as3722 4-0040: Failed to read IRQ status: -16 as3722 4-0040: Failed to read IRQ status: -16 as3722 4-0040: Failed to read IRQ status: -16 ... The reason why the as3722 interrupt status cannot be read is because the as3722 interrupt is not masked during suspend and when the as3722-rtc interrupt occurs, to wake-up the device, the interrupt is seen before the i2c controller has been resumed in order to read the as3722 interrupt status. The as3722-rtc driver sets it's interrupt as a wake-up source during suspend, which gets propagated to the parent as3722 interrupt. However, the as3722-rtc driver cannot disable it's interrupt during suspend otherwise we would never be woken up and so the as3722 must disable it's interrupt instead. Fix this by disabling the as3722 interrupt during suspend. To ensure that a wake-up event from the as3722 is not missing, enable the as3722 interrupt as a wake-up source before disabling the interrupt on entering suspend. Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
chenzefeng (A) authored
BugLink: https://bugs.launchpad.net/bugs/1818815Signed-off-by:
chenzefeng <chenzefeng2@huawei.com> On x86-64, for 32-bit PC-relacive branches, we can generate PLT32 relocation, instead of PC32 relocation. and R_X86_64_PLT32 can be treated the same as R_X86_64_PC32 since linux kernel doesn't use PLT. commit b21ebf2f ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") been fixed for the module loading, but not fixed for livepatch relocation, which will fail to load livepatch with the error message as follow: relocation failed for symbol <symbol name> at <symbol address> This issue only effacted the kernel version from 4.0 to 4.6, becauce the function klp_write_module_reloc is introduced by: commit b700e7f0 ("livepatch: kernel: add support for live patching") and deleted by: commit 425595a7 ("livepatch: reuse module loader code to write relocations") Signed-off-by:
Petr Mladek <pmladek@suse.com> Signed-off-by:
-
Lorenzo Bianconi authored
BugLink: https://bugs.launchpad.net/bugs/1818815 [ Upstream commit c09551c6 ] According to the algorithm described in the comment block at the beginning of ip_rt_send_redirect, the host should try to send 'ip_rt_redirect_number' ICMP redirect packets with an exponential backoff and then stop sending them at all assuming that the destination ignores redirects. If the device has previously sent some ICMP error packets that are rate-limited (e.g TTL expired) and continues to receive traffic, the redirect packets will never be transmitted. This happens since peer->rate_tokens will be typically greater than 'ip_rt_redirect_number' and so it will never be reset even if the redirect silence timeout (ip_rt_redirect_silence) has elapsed without receiving any packet requiring redirects. Fix it by using a dedicated counter for the number of ICMP redirect packets that has been sent by the host I have not been able to identify a given commit that introduced the issue since ip_rt_send_redirect implements the same rate-limiting algorithm from commit 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Jose Abreu authored
BugLink: https://bugs.launchpad.net/bugs/1818815 [ Upstream commit 8a7493e5 ] We are saving the status of EEE even before we try to enable it. This leads to a race with XMIT function that tries to arm EEE timer before we set it up. Fix this by only saving the EEE parameters after all operations are performed with success. Signed-off-by:
Jose Abreu <joabreu@synopsys.com> Fixes: d765955d ("stmmac: add the Energy Efficient Ethernet support") Cc: Joao Pinto <jpinto@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1818815 [ Upstream commit 4179cb5a ] netif_rx() must be called under a strict contract. At device dismantle phase, core networking clears IFF_UP and flush_all_backlogs() is called after rcu grace period to make sure no incoming packet might be in a cpu backlog and still referencing the device. Most drivers call netif_rx() from their interrupt handler, and since the interrupts are disabled at device dismantle, netif_rx() does not have to check dev->flags & IFF_UP Virtual drivers do not have this guarantee, and must therefore make the check themselves. Otherwise we risk use-after-free and/or crashes. Note this patch also fixes a small issue that came with commit ce6502a8 ("vxlan: fix a use after free in vxlan_encap_bypass"), since the dev->stats.rx_dropped change was done on the wrong device. Fixes: d342894c ("vxlan: virtual extensible lan") Fixes: ce6502a8 ("vxlan: fix a use after free in vxlan_encap_bypass") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Petr Machata <petrm@mellanox.com> Cc: Ido Schimmel <idosch@mellanox.com> Cc: Roopa Prabhu <roopa@cumulusnetworks.com> Cc: Stefano Brivio <sbrivio@redhat.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1818815 [ Upstream commit 04c03114 ] soukjin bae reported a crash in tcp_v4_err() handling ICMP_DEST_UNREACH after tcp_write_queue_head(sk) returned a NULL pointer. Current logic should have prevented this : if (seq != tp->snd_una || !icsk->icsk_retransmits || !icsk->icsk_backoff || fastopen) break; Problem is the write queue might have been purged and icsk_backoff has not been cleared. Signed-off-by:
soukjin bae <soukjin.bae@samsung.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Alexander Duyck authored
BugLink: https://bugs.launchpad.net/bugs/1818815 [ Upstream commit 3bed3cc4 ] This patch addresses the fact that there are drivers, specifically tun, that will call into the network page fragment allocators with buffer sizes that are not cache aligned. Doing this could result in data alignment and DMA performance issues as these fragment pools are also shared with the skb allocator and any other devices that will use napi_alloc_frags or netdev_alloc_frags. Fixes: ffde7328 ("net: Split netdev_alloc_frag into __alloc_page_frag and add __napi_alloc_frag") Reported-by:
Jann Horn <jannh@google.com> Signed-off-by:
Alexander Duyck <alexander.h.duyck@linux.intel.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1818815 [ Upstream commit 2c4cc971 ] ICMP handlers are not very often stressed, we should make them more resilient to bugs that might surface in the future. If there is no packet in retransmit queue, we should avoid a NULL deref. Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
-
David S. Miller authored
BugLink: https://bugs.launchpad.net/bugs/1818815 [ Upstream commit 8681ef1f ] Fixes: 3b89ea9c ("net: Fix for_each_netdev_feature on Big endian") Suggested-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Kai-Heng Feng authored
BugLink: https://bugs.launchpad.net/bugs/1818815 [ Upstream commit 1765f5dc ] Another platform requires even longer delay to make the device work correctly after S3. So increase the delay to 300ms. BugLink: https://bugs.launchpad.net/bugs/1798921Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Hauke Mehrtens authored
BugLink: https://bugs.launchpad.net/bugs/1818815 [ Upstream commit 3b89ea9c ] The features attribute is of type u64 and stored in the native endianes on the system. The for_each_set_bit() macro takes a pointer to a 32 bit array and goes over the bits in this area. On little Endian systems this also works with an u64 as the most significant bit is on the highest address, but on big endian the words are swapped. When we expect bit 15 here we get bit 47 (15 + 32). This patch converts it more or less to its own for_each_set_bit() implementation which works on 64 bit integers directly. This is then completely in host endianness and should work like expected. Fixes: fd867d51 ("net/core: generic support for disabling netdev features down stack") Signed-off-by:
Hauke Mehrtens <hauke.mehrtens@intel.com> Signed-off-by:
-
Wei Yongjun authored
BugLink: https://bugs.launchpad.net/bugs/1818815 [ Upstream commit 07bd14cc ] Add the missing unlock before return from function set_fan_div() in the error handling case. Fixes: c9c63915 ("hwmon: (lm80) fix a missing check of the status of SMBus read") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Paolo Abeni authored
BugLink: https://bugs.launchpad.net/bugs/1818815 [ Upstream commit 225d9464 ] In the unlikely event that the kmalloc call in vmci_transport_socket_init() fails, we end-up calling vmci_transport_destruct() with a NULL vmci_trans() and oopsing. This change addresses the above explicitly checking for zero vmci_trans() at destruction time. Reported-by:
Xiumei Mu <xmu@redhat.com> Fixes: d021c344 ("VSOCK: Introduce VM Sockets") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Jorgen Hansen <jhansen@vmware.com> Signed-off-by:
-
Zhiqiang Liu authored
BugLink: https://bugs.launchpad.net/bugs/1818815 [ Upstream commit e75913c9 ] Follow those steps: # ip addr add 2001:123::1/32 dev eth0 # ip addr add 2001:123:456::2/64 dev eth0 # ip addr del 2001:123::1/32 dev eth0 # ip addr del 2001:123:456::2/64 dev eth0 and then prefix route of 2001:123::1/32 will still exist. This is because ipv6_prefix_equal in check_cleanup_prefix_route func does not check whether two IPv6 addresses have the same prefix length. If the prefix of one address starts with another shorter address prefix, even though their prefix lengths are different, the return value of ipv6_prefix_equal is true. Here I add a check of whether two addresses have the same prefix to decide whether their prefixes are equal. Fixes: 5b84efec ("ipv6 addrconf: don't cleanup prefix route for IFA_F_NOPREFIXROUTE") Signed-off-by:
Zhiqiang Liu <liuzhiqiang26@huawei.com> Reported-by:
Wenhao Zhang <zhangwenhao8@huawei.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1818813Signed-off-by:
-
Hauke Mehrtens authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit da360299 upstream. This fixes a compile problem of some user space applications by not including linux/libc-compat.h in uapi/if_ether.h. linux/libc-compat.h checks which "features" the header files, included from the libc, provide to make the Linux kernel uapi header files only provide no conflicting structures and enums. If a user application mixes kernel headers and libc headers it could happen that linux/libc-compat.h gets included too early where not all other libc headers are included yet. Then the linux/libc-compat.h would not prevent all the redefinitions and we run into compile problems. This patch removes the include of linux/libc-compat.h from uapi/if_ether.h to fix the recently introduced case, but not all as this is more or less impossible. It is no problem to do the check directly in the if_ether.h file and not in libc-compat.h as this does not need any fancy glibc header detection as glibc never provided struct ethhdr and should define __UAPI_DEF_ETHHDR by them self when they will provide this. The following test program did not compile correctly any more: #include <linux/if_ether.h> #include <netinet/in.h> #include <linux/in.h> int main(void) { return 0; } Fixes: 6926e041 ("uapi/if_ether.h: prevent redefinition of struct ethhdr") Reported-by:
Guillaume Nault <g.nault@alphalink.fr> Cc: <stable@vger.kernel.org> # 4.15 Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Christian Lamparter authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit a86caa9b upstream. Sven Eckelmann reported an issue with the current IPQ4019 pinctrl. Setting up any gpio-hog in the device-tree for his device would "kill the bootup completely": | [ 0.477838] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe | [ 0.499828] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferring probe | [ 1.298883] requesting hog GPIO enable USB2 power (chip 1000000.pinctrl, offset 58) failed, -517 | [ 1.299609] gpiochip_add_data: GPIOs 0..99 (1000000.pinctrl) failed to register | [ 1.308589] ipq4019-pinctrl 1000000.pinctrl: Failed register gpiochip | [ 1.316586] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe | [ 1.322415] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferri This was also verified on a RT-AC58U (IPQ4018) which would no longer boot, if a gpio-hog was specified. (Tried forcing the USB LED PIN (GPIO0) to high.). The problem is that Pinctrl+GPIO registration is currently peformed in the following order in pinctrl-msm.c: 1. pinctrl_register() 2. gpiochip_add() 3. gpiochip_add_pin_range() The actual error code -517 == -EPROBE_DEFER is coming from pinctrl_get_device_gpio_range(), which is called through: gpiochip_add of_gpiochip_add of_gpiochip_scan_gpios gpiod_hog gpiochip_request_own_desc __gpiod_request chip->request gpiochip_generic_request pinctrl_gpio_request pinctrl_get_device_gpio_range pinctrl_get_device_gpio_range() is unable to find any valid pin ranges, since nothing has been added to the pinctrldev_list yet. so the range can't be found, and the operation fails with -EPROBE_DEFER. This patch fixes the issue by adding the "gpio-ranges" property to the pinctrl device node of all upstream Qcom SoC. The pin ranges are then added by the gpio core. In order to remain compatible with older, existing DTs (and ACPI) a check for the "gpio-ranges" property has been added to msm_gpio_init(). This prevents the driver of adding the same entry to the pinctrldev_list twice. Reported-by:
Sven Eckelmann <sven.eckelmann@openmesh.com> Tested-by: Sven Eckelmann <sven.eckelmann@openmesh.com> [ipq4019] Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Christian Lamparter <chunkeey@gmail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
-
John Youn authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit cd4b1e34 upstream. This shouldn't be freed by the HCD as it is owned by the core and allocated with devm_kzalloc. Signed-off-by:
John Youn <johnyoun@synopsys.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit 39fba783 upstream. We can use skb_cow_head() to properly deal with clones, especially the ones coming from TCP stack that allow their head being modified. This avoids a copy. Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit 6bc6895b upstream. We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: 4a476bd6 ("usbnet: New driver for QinHeng CH9200 devices") Signed-off-by:
-
James Hughes authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit e9156cd2 upstream. The driver was failing to check that the SKB wasn't cloned before adding checksum data. Replace existing handling to extend/copy the header buffer with skb_cow_head. Signed-off-by:
James Hughes <james.hughes@raspberrypi.org> Acked-by:
Woojung Huh <Woojung.Huh@microchip.com> Signed-off-by:
-
Nikos Tsironis authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit 4ae280b4 upstream. When provisioning a new data block for a virtual block, either because the block was previously unallocated or because we are breaking sharing, if the whole block of data is being overwritten the bio that triggered the provisioning is issued immediately, skipping copying or zeroing of the data block. When this bio completes the new mapping is inserted in to the pool's metadata by process_prepared_mapping(), where the bio completion is signaled to the upper layers. This completion is signaled without first committing the metadata. If the bio in question has the REQ_FUA flag set and the system crashes right after its completion and before the next metadata commit, then the write is lost despite the REQ_FUA flag requiring that I/O completion for this request must only be signaled after the data has been committed to non-volatile storage. Fix this by deferring the completion of overwrite bios, with the REQ_FUA flag set, until after the metadata has been committed. Cc: stable@vger.kernel.org Signed-off-by:
Nikos Tsironis <ntsironis@arrikto.com> Acked-by:
Joe Thornber <ejt@redhat.com> Acked-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Borislav Petkov authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit 10970e1b upstream. dump_thread32() in aout_core_dump() does not clear the user32 structure allocated on the stack as the first thing on function entry. As a result, the dump.u_comm, dump.u_ar0 and dump.signal which get assigned before the clearing, get overwritten. Rename that function to fill_dump() to make it clear what it does and call it first thing. This was caught while staring at a patch by Derek Robson <robsonde@gmail.com>. Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: Derek Robson <robsonde@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Matz <matz@suse.de> Cc: x86@kernel.org Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20190202005512.3144-1-robsonde@gmail.comSigned-off-by:
-
Eric W. Biederman authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit cf43a757 upstream. In the middle of do_exit() there is there is a call "ptrace_event(PTRACE_EVENT_EXIT, code);" That call places the process in TACKED_TRACED aka "(TASK_WAKEKILL | __TASK_TRACED)" and waits for for the debugger to release the task or SIGKILL to be delivered. Skipping past dequeue_signal when we know a fatal signal has already been delivered resulted in SIGKILL remaining pending and TIF_SIGPENDING remaining set. This in turn caused the scheduler to not sleep in PTACE_EVENT_EXIT as it figured a fatal signal was pending. This also caused ptrace_freeze_traced in ptrace_check_attach to fail because it left a per thread SIGKILL pending which is what fatal_signal_pending tests for. This difference in signal state caused strace to report strace: Exit of unknown pid NNNNN ignored Therefore update the signal handling state like dequeue_signal would when removing a per thread SIGKILL, by removing SIGKILL from the per thread signal mask and clearing TIF_SIGPENDING. Acked-by:
Oleg Nesterov <oleg@redhat.com> Reported-by:
Ivan Delalande <colona@arista.com> Cc: stable@vger.kernel.org Fixes: 35634ffa ("signal: Always notice exiting tasks") Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Hedi Berriche authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit f331e766 upstream. Calls into UV firmware must be protected against concurrency, expose the efi_runtime_lock to the UV platform, and use it to serialise UV BIOS calls. Signed-off-by:
Hedi Berriche <hedi.berriche@hpe.com> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by:
Russ Anderson <rja@hpe.com> Reviewed-by:
Dimitri Sivanich <sivanich@hpe.com> Reviewed-by:
Mike Travis <mike.travis@hpe.com> Cc: Andy Shevchenko <andy@infradead.org> Cc: Bhupesh Sharma <bhsharma@redhat.com> Cc: Darren Hart <dvhart@infradead.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-efi <linux-efi@vger.kernel.org> Cc: platform-driver-x86@vger.kernel.org Cc: stable@vger.kernel.org # v4.9+ Cc: Steve Wahl <steve.wahl@hpe.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berriche@hpe.comSigned-off-by:
-
Andreas Ziegler authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit 0722069a upstream. When printing multiple uprobe arguments as strings the output for the earlier arguments would also include all later string arguments. This is best explained in an example: Consider adding a uprobe to a function receiving two strings as parameters which is at offset 0xa0 in strlib.so and we want to print both parameters when the uprobe is hit (on x86_64): $ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \ /sys/kernel/debug/tracing/uprobe_events When the function is called as func("foo", "bar") and we hit the probe, the trace file shows a line like the following: [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar" Note the extra "bar" printed as part of arg1. This behaviour stacks up for additional string arguments. The strings are stored in a dynamically growing part of the uprobe buffer by fetch_store_string() after copying them from userspace via strncpy_from_user(). The return value of strncpy_from_user() is then directly used as the required size for the string. However, this does not take the terminating null byte into account as the documentation for strncpy_from_user() cleary states that it "[...] returns the length of the string (not including the trailing NUL)" even though the null byte will be copied to the destination. Therefore, subsequent calls to fetch_store_string() will overwrite the terminating null byte of the most recently fetched string with the first character of the current string, leading to the "accumulation" of strings in earlier arguments in the output. Fix this by incrementing the return value of strncpy_from_user() by one if we did not hit the maximum buffer size. Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de Cc: Ingo Molnar <mingo@redhat.com> Cc: stable@vger.kernel.org Fixes: 5baaa59e ("tracing/probes: Implement 'memory' fetch method for uprobes") Acked-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Andreas Ziegler <andreas.ziegler@fau.de> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Meelis Roos authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit bfc91368 upstream. Eiger machine vector definition has nr_irqs 128, and working 2.6.26 boot shows SCSI getting IRQ-s 64 and 65. Current kernel boot fails because Symbios SCSI fails to request IRQ-s and does not find the disks. It has been broken at least since 3.18 - the earliest I could test with my gcc-5. The headers have moved around and possibly another order of defines has worked in the past - but since 128 seems to be correct and used, fix arch/alpha/include/asm/irq.h to have NR_IRQS=128 for Eiger. This fixes 4.19-rc7 boot on my Force Flexor A264 (Eiger subarch). Cc: stable@vger.kernel.org # v3.18+ Signed-off-by:
Meelis Roos <mroos@linux.ee> Signed-off-by:
Matt Turner <mattst88@gmail.com> Signed-off-by:
-
Sergei Trofimovich authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit 491af60f upstream. Fix page fault handling code to fixup r16-r18 registers. Before the patch code had off-by-two registers bug. This bug caused overwriting of ps,pc,gp registers instead of fixing intended r16,r17,r18 (see `struct pt_regs`). More details: Initially Dmitry noticed a kernel bug as a failure on strace test suite. Test passes unmapped userspace pointer to io_submit: ```c #include <err.h> #include <unistd.h> #include <sys/mman.h> #include <asm/unistd.h> int main(void) { unsigned long ctx = 0; if (syscall(__NR_io_setup, 1, &ctx)) err(1, "io_setup"); const size_t page_size = sysconf(_SC_PAGESIZE); const size_t size = page_size * 2; void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (MAP_FAILED == ptr) err(1, "mmap(%zu)", size); if (munmap(ptr, size)) err(1, "munmap"); syscall(__NR_io_submit, ctx, 1, ptr + page_size); syscall(__NR_io_destroy, ctx); return 0; } ``` Running this test causes kernel to crash when handling page fault: ``` Unable to handle kernel paging request at virtual address ffffffffffff9468 CPU 3 aio(26027): Oops 0 pc = [<fffffc00004eddf8>] ra = [<fffffc00004edd5c>] ps = 0000 Not tainted pc is at sys_io_submit+0x108/0x200 ra is at sys_io_submit+0x6c/0x200 v0 = fffffc00c58e6300 t0 = fffffffffffffff2 t1 = 000002000025e000 t2 = fffffc01f159fef8 t3 = fffffc0001009640 t4 = fffffc0000e0f6e0 t5 = 0000020001002e9e t6 = 4c41564e49452031 t7 = fffffc01f159c000 s0 = 0000000000000002 s1 = 000002000025e000 s2 = 0000000000000000 s3 = 0000000000000000 s4 = 0000000000000000 s5 = fffffffffffffff2 s6 = fffffc00c58e6300 a0 = fffffc00c58e6300 a1 = 0000000000000000 a2 = 000002000025e000 a3 = 00000200001ac260 a4 = 00000200001ac1e8 a5 = 0000000000000001 t8 = 0000000000000008 t9 = 000000011f8bce30 t10= 00000200001ac440 t11= 0000000000000000 pv = fffffc00006fd320 at = 0000000000000000 gp = 0000000000000000 sp = 00000000265fd174 Disabling lock debugging due to kernel taint Trace: [<fffffc0000311404>] entSys+0xa4/0xc0 ``` Here `gp` has invalid value. `gp is s overwritten by a fixup for the following page fault handler in `io_submit` syscall handler: ``` __se_sys_io_submit ... ldq a1,0(t1) bne t0,4280 <__se_sys_io_submit+0x180> ``` After a page fault `t0` should contain -EFALUT and `a1` is 0. Instead `gp` was overwritten in place of `a1`. This happens due to a off-by-two bug in `dpf_reg()` for `r16-r18` (aka `a0-a2`). I think the bug went unnoticed for a long time as `gp` is one of scratch registers. Any kernel function call would re-calculate `gp`. Dmitry tracked down the bug origin back to 2.1.32 kernel version where trap_a{0,1,2} fields were inserted into struct pt_regs. And even before that `dpf_reg()` contained off-by-one error. Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: linux-alpha@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reported-and-reviewed-by:
"Dmitry V. Levin" <ldv@altlinux.org> Cc: stable@vger.kernel.org # v2.1.32+ Bug: https://bugs.gentoo.org/672040Signed-off-by:
Sergei Trofimovich <slyfox@gentoo.org> Signed-off-by:
-
Matti Kurkela authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit e8b22d0a upstream. Like Fujitsu CELSIUS H760, the H780 also has a three-button Elantech touchpad, but the driver needs to be told so to enable the middle touchpad button. The elantech_dmi_force_crc_enabled quirk was not necessary with the H780. Also document the fw_version and caps values detected for both H760 and H780 models. Signed-off-by:
Matti Kurkela <Matti.Kurkela@iki.fi> Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Jonathan Bakker authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit 90cc55f0 upstream. Otherwise we introduce a race condition where userspace can request input before we're ready leading to null pointer dereference such as input: bma150 as /devices/platform/i2c-gpio-2/i2c-5/5-0038/input/input3 Unable to handle kernel NULL pointer dereference at virtual address 00000018 pgd = (ptrval) [00000018] *pgd=55dac831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT ARM Modules linked in: bma150 input_polldev [last unloaded: bma150] CPU: 0 PID: 2870 Comm: accelerometer Not tainted 5.0.0-rc3-dirty #46 Hardware name: Samsung S5PC110/S5PV210-based board PC is at input_event+0x8/0x60 LR is at bma150_report_xyz+0x9c/0xe0 [bma150] pc : [<80450f70>] lr : [<7f0a614c>] psr: 800d0013 sp : a4c1fd78 ip : 00000081 fp : 00020000 r10: 00000000 r9 : a5e2944c r8 : a7455000 r7 : 00000016 r6 : 00000101 r5 : a7617940 r4 : 80909048 r3 : fffffff2 r2 : 00000000 r1 : 00000003 r0 : 00000000 Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 54e34019 DAC: 00000051 Process accelerometer (pid: 2870, stack limit = 0x(ptrval)) Stackck: (0xa4c1fd78 to 0xa4c20000) fd60: fffffff3 fc813f6c fd80: 40410581 d7530ce3 a5e2817c a7617f00 a5e29404 a5e2817c 00000000 7f008324 fda0: a5e28000 8044f59c a5fdd9d0 a5e2945c a46a4a00 a5e29668 a7455000 80454f10 fdc0: 80909048 a5e29668 a5fdd9d0 a46a4a00 806316d0 00000000 a46a4a00 801df5f0 fde0: 00000000 d7530ce3 a4c1fec0 a46a4a00 00000000 a5fdd9d0 a46a4a08 801df53c fe00: 00000000 801d74bc a4c1fec0 00000000 a4c1ff70 00000000 a7038da8 00000000 fe20: a46a4a00 801e91fc a411bbe0 801f2e88 00000004 00000000 80909048 00000041 fe40: 00000000 00020000 00000000 dead4ead a6a88da0 00000000 ffffe000 806fcae8 fe60: a4c1fec8 00000000 80909048 00000002 a5fdd9d0 a7660110 a411bab0 00000001 fe80: dead4ead ffffffff ffffffff a4c1fe8c a4c1fe8c d7530ce3 20000013 80909048 fea0: 80909048 a4c1ff70 00000001 fffff000 a4c1e000 00000005 00026038 801eabd8 fec0: a7660110 a411bab0 b9394901 00000006 a696201b 76fb3000 00000000 a7039720 fee0: a5fdd9d0 00000101 00000002 00000096 00000000 00000000 00000000 a4c1ff00 ff00: a6b310f4 805cb174 a6b310f4 00000010 00000fe0 00000010 a4c1e000 d7530ce3 ff20: 00000003 a5f41400 a5f41424 00000000 a6962000 00000000 00000003 00000002 ff40: ffffff9c 000a0000 80909048 d7530ce3 a6962000 00000003 80909048 ffffff9c ff60: a6962000 801d890c 00000000 00000000 00020000 a7590000 00000004 00000100 ff80: 00000001 d7530ce3 000288b8 00026320 000288b8 00000005 80101204 a4c1e000 ffa0: 00000005 80101000 000288b8 00026320 000288b8 000a0000 00000000 00000000 ffc0: 000288b8 00026320 000288b8 00000005 7eef3bac 000264e8 00028ad8 00026038 ffe0: 00000005 7eef3300 76f76e91 76f78546 800d0030 000288b8 00000000 00000000 [<80450f70>] (input_event) from [<a5e2817c>] (0xa5e2817c) Code: e1a08148 eaffffa8 e351001f 812fff1e (e590c018) ---[ end trace 1c691ee85f2ff243 ]--- Signed-off-by:
Jonathan Bakker <xc-racer2@live.ca> Signed-off-by:
Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Manuel Reinhardt authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit 2bc16b9f upstream. The commit a60945fd ("ALSA: usb-audio: move implicit fb quirks to separate function") introduced an error in the handling of quirks for implicit feedback endpoints. This commit fixes this. If a quirk successfully sets up an implicit feedback endpoint, usb-audio no longer tries to find the implicit fb endpoint itself. Fixes: a60945fd ("ALSA: usb-audio: move implicit fb quirks to separate function") Signed-off-by:
Manuel Reinhardt <manuel.rhdt@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jurica Vukadin authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit 4cd3016c upstream. This enables mute LED support and fixes switching jacks when the laptop is docked. Signed-off-by:
Jurica Vukadin <jurica.vukadin@rt-rk.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Ingo Molnar authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit 528871b4 upstream. The following commit: 9dff0aa9 ("perf/core: Don't WARN() for impossible ring-buffer sizes") results in perf recording failures with larger mmap areas: root@skl:/tmp# perf record -g -a failed to mmap with 12 (Cannot allocate memory) The root cause is that the following condition is buggy: if (order_base_2(size) >= MAX_ORDER) goto fail; The problem is that @size is in bytes and MAX_ORDER is in pages, so the right test is: if (order_base_2(size) >= PAGE_SHIFT+MAX_ORDER) goto fail; Fix it. Reported-by:
"Jin, Yao" <yao.jin@linux.intel.com> Bisected-by:
Borislav Petkov <bp@alien8.de> Analyzed-by:
Peter Zijlstra <peterz@infradead.org> Cc: Julien Thierry <julien.thierry@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: <stable@vger.kernel.org> Fixes: 9dff0aa9 ("perf/core: Don't WARN() for impossible ring-buffer sizes") Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Mauro Ciancio authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit 7ad222b3 upstream. This adds ELAN0617 to the ACPI table to support Elan touchpad found in Lenovo V330-15ISK. Signed-off-by:
Mauro Ciancio <mauro@acadeu.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Dmitry Torokhov authored
BugLink: https://bugs.launchpad.net/bugs/1818813 commit f420c54e upstream. This reverts commit 7db54c89 as it breaks Acer Aspire V-371 and other devices. According to Elan: "Acer Aspire F5-573G is MS Precision touchpad which should use hid multitouch driver. ELAN0501 should not be added in elan_i2c." Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202503 Cc: stable@vger.kernel.org Signed-off-by:
-
Mark Rustad authored
BugLink: https://bugs.launchpad.net/bugs/1818813 It seemed odd to say "since 4.17" in a 4.4 kernel. Consider rewording the reference to indicate where in the stable series it was introduced as well as where it originated. Signed-off-by:
Mark Rustad <mrustad@gmail.com> Signed-off-by:
-
Ross Lagerwall authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 92a8109e ] The code tries to allocate a contiguous buffer with a size supplied by the server (maxBuf). This could fail if memory is fragmented since it results in high order allocations for commonly used server implementations. It is also wasteful since there are probably few locks in the usual case. Limit the buffer to be no larger than a page to avoid memory allocation failures due to fragmentation. Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
Nicholas Mc Guire authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit df209c43 ] devm_kzalloc(), devm_kstrdup() and devm_kasprintf() all can fail internal allocation and return NULL. Using any of the assigned objects without checking is not safe. As this is early in the boot phase and these allocations really should not fail, any failure here is probably an indication of a more serious issue so it makes little sense to try and rollback the previous allocated resources or try to continue; but rather the probe function is simply exited with -ENOMEM. Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Fixes: 684284b6 ("ARM: integrator: add MMCI device to IM-PD1") Signed-off-by:
-
Linus Walleij authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit b5f03484 ] These two lines are active high, not active low. The bug was found when we changed the kernel to respect the polarity defined in the device tree. Fixes: 1b90e06b ("ARM: kirkwood: Use devicetree to define DNS-32[05] fan") Cc: Jamie Lentin <jm@lentin.co.uk> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory Clement <gregory.clement@bootlin.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Julien D'Ascenzio <jdascenzio@posteo.net> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Tested-by:
Jamie Lentin <jm@lentin.co.uk> Reported-by:
Julien D'Ascenzio <jdascenzio@posteo.net> Tested-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by:
-
Peter Ujfalusi authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 7fca69d4 ] To avoid the following error: asoc-simple-card sound: ASoC: Failed to create card debugfs directory Which is because the card name contains '/' character, which can not be used in file or directory names. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
