- 13 Apr, 2018 40 commits
-
-
Thomas Bogendoerfer authored
[ Upstream commit e279e6d9 ] sccnxp driver doesn't get the correct uart clock rate, if CONFIG_HAVE_CLOCK is disabled. Correct usage of clk API to make it work with/without it. Fixes: 90efa75f (serial: sccnxp: Using CLK API for getting UART clock) Suggested-by:
Russell King - ARM Linux <linux@armlinux.org.uk> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Ganesh Goudar authored
[ Upstream commit a97051f4 ] take care of UpDbgLaRdPtr[0-3] restriction for T6. Signed-off-by:
Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Christophe Leroy authored
[ Upstream commit 3c29b603 ] IRQ 0 is a valid HW interrupt. So get_irq() shall return 0 when there is no irq, instead of returning irq_linear_revmap(... ,0) Fixes: f2a0bd37 ("[POWERPC] 8xx: powerpc port of core CPM PIC") Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Tomi Valkeinen authored
[ Upstream commit cc8dd766 ] omap_gem uses page alignment for buffer stride. The related calculations are a bit off, though, as byte stride of 4096 gets aligned to 8192, instead of 4096. This patch changes the code to use DIV_ROUND_UP(), which fixes those calculations and makes them more readable. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Steven L. Roberts authored
[ Upstream commit c4dd4b69 ] This fixes a kernel panic when loading the hfi driver as a dynamic module. Signed-off-by:
Steven L Roberts <robers97@gmail.com> Reviewed-by:
Leon Romanovsky <leon@kernel.org> Acked-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Raju Rangoju authored
[ Upstream commit 1dad0ebe ] The patch 761e19a5 (RDMA/iw_cxgb4: Handle return value of c4iw_ofld_send() in abort_arp_failure()) from May 6, 2016 leads to the following static checker warning: drivers/infiniband/hw/cxgb4/cm.c:575 abort_arp_failure() warn: passing freed memory 'skb' Also fixes skb leak when l2t resolution fails Fixes: 761e19a5 (RDMA/iw_cxgb4: Handle return value of c4iw_ofld_send() in abort_arp_failure()) Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Raju Rangoju <rajur@chelsio.com> Reviewed-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
-
Leonard Crestez authored
[ Upstream commit 79e498a9 ] These bits seem to be lost after a suspend/resume cycle so just set them again. Do this by splitting the handling of these bits into a function that is also called on resume. This patch fixes ethernet suspend/resume on imx6ul-14x14-evk boards. Signed-off-by:
Leonard Crestez <leonard.crestez@nxp.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Jia-Ju Bai authored
[ Upstream commit 93818da5 ] The driver may sleep under a read spin lock, and the function call path is: send_socklist (acquire the lock by read_lock) skb_copy(GFP_KERNEL) --> may sleep To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC". Signed-off-by:
Jia-Ju Bai <baijiaju1990@163.com> Signed-off-by:
-
Ard Biesheuvel authored
[ Upstream commit 1151f838 ] When running lscpu on an AArch64 system that has SMBIOS version 2.0 tables, it will segfault in the following way: Unable to handle kernel paging request at virtual address ffff8000bfff0000 pgd = ffff8000f9615000 [ffff8000bfff0000] *pgd=0000000000000000 Internal error: Oops: 96000007 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 task: ffff8000fa78e800 task.stack: ffff8000f9780000 PC is at __arch_copy_to_user+0x90/0x220 LR is at read_mem+0xcc/0x140 This is caused by the fact that lspci issues a read() on /dev/mem at the offset where it expects to find the SMBIOS structure array. However, this region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec), and so it is omitted from the linear mapping. So let's restrict /dev/mem read/write access to those areas that are covered by the linear region. Reported-by:
Alexander Graf <agraf@suse.de> Fixes: 4dffbfc4 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Jia-Ju Bai authored
[ Upstream commit 5ea6d691 ] The driver may sleep under a write spin lock, and the function call path is: qlcnic_82xx_hw_write_wx_2M (acquire the lock by write_lock_irqsave) crb_win_lock qlcnic_pcie_sem_lock usleep_range qlcnic_82xx_hw_read_wx_2M (acquire the lock by write_lock_irqsave) crb_win_lock qlcnic_pcie_sem_lock usleep_range To fix it, the usleep_range is replaced with udelay. Signed-off-by:
-
Jiri Olsa authored
[ Upstream commit 54265664 ] The s390 architecture maps sys_mmap (nr 90) into sys_old_mmap. For this reason perf trace can't find the proper syscall event to get args format from and displays it wrongly as 'continued'. To fix that fill the "alias" field with "old_mmap" for trace's mmap record to get the correct translation. Before: 0.042 ( 0.011 ms): vest/43052 fstat(statbuf: 0x3ffff89fd90 ) = 0 0.042 ( 0.028 ms): vest/43052 ... [continued]: mmap()) = 0x3fffd6e2000 0.072 ( 0.025 ms): vest/43052 read(buf: 0x3fffd6e2000, count: 4096 ) = 6 After: 0.045 ( 0.011 ms): fstat(statbuf: 0x3ffff8a0930 ) = 0 0.057 ( 0.018 ms): mmap(arg: 0x3ffff8a0858 ) = 0x3fffd14a000 0.076 ( 0.025 ms): read(buf: 0x3fffd14a000, count: 4096 ) = 6 Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/20170531113557.19175-1-jolsa@kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Anilkumar Kolli authored
[ Upstream commit a9f5f287 ] QCA99X0, QCA9888, QCA9984 supports calibration data in either OTP or DT/pre-cal file. Current ath10k supports Calibration data from OTP only. If caldata is loaded from DT/pre-cal file, fetching board id and applying calibration parameters like tx power gets failed. error log: [ 15.733663] ath10k_pci 0000:01:00.0: failed to fetch board file: -2 [ 15.741474] ath10k_pci 0000:01:00.0: could not probe fw (-2) This patch adds calibration data support from DT/pre-cal file. Below parameters are used to get board id and applying calibration parameters from cal data. EEPROM[OTP] FLASH[DT/pre-cal file] Cal param 0x700 0x10000 Board id 0x10 0x8000 Tested on QCA9888 with pre-cal file. Signed-off-by:
Anilkumar Kolli <akolli@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit b312b2b2 ] We accidentally return ERR_PTR(0) which is NULL. The caller is not expecting that and it leads to an Oops. Fixes: dd59239a ("amdkfd: init aperture once per process") Signed-off-by:
Felix Kuehling <felix.kuehling@amd.com> Signed-off-by:
Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by:
-
Michael Ellerman authored
[ Upstream commit 99acc9be ] If a process dumps core while it has SPU contexts active then we have code to also dump information about the SPU contexts. Unfortunately it's been broken for 3 1/2 years, and we didn't notice. In commit 7b1f4020 ("spufs: get rid of dump_emit() wrappers") the nread variable was removed and rc used instead. That means when the loop exits successfully, rc has the number of bytes read, but it's then used as the return value for the function, which should return 0 on success. So fix it by setting rc = 0 before returning in the success case. Fixes: 7b1f4020 ("spufs: get rid of dump_emit() wrappers") Signed-off-by:
Jeremy Kerr <jk@ozlabs.org> Signed-off-by:
-
Bryan O'Donoghue authored
[ Upstream commit ee177c5d ] When failing to set a clock the printout emitted is incorrect. "u32 rate" is formatted as %d and should be %u whereas "unsigned long clk_set_rate()" is formatted as %ld and should be %lu as per Documentation/printk-formats.txt. Fixes: 2885c3b2 ("clk: Show correct information when fail to set clock rate") Signed-off-by:
Bryan O'Donoghue <pure.logic@nexus-software.ie> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Sudeep Holla authored
[ Upstream commit 7374aec9 ] The frequencies above the maximum value of signed integer(i.e. 2^31 -1) will overflow with the current code. This patch fixes the return type of __scpi_dvfs_round_rate from 'int' to 'unsigned long'. Fixes: cd52c2a4 ("clk: add support for clocks provided by SCP(System Control Processor)") Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Roman Pen authored
[ Upstream commit d9c1b543 ] This is a fix for the problem [1], where VMCB.CPL was set to 0 and interrupt was taken on userspace stack. The root cause lies in the specific AMD CPU behaviour which manifests itself as unusable segment attributes on SYSRET. The corresponding work around for the kernel is the following: 61f01dd9 ("x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue") In other turn virtualization side treated unusable segment incorrectly and restored CPL from SS attributes, which were zeroed out few lines above. In current patch it is assured only that P bit is cleared in VMCB.save state and segment attributes are not zeroed out if segment is not presented or is unusable, therefore CPL can be safely restored from DPL field. This is only one part of the fix, since QEMU side should be fixed accordingly not to zero out attributes on its side. Corresponding patch will follow. [1] Message id: CAJrWOzD6Xq==b-zYCDdFLgSRMPM-NkNuTSDFEtX=7MreT45i7Q@mail.gmail.com Signed-off-by:
Roman Pen <roman.penyaev@profitbricks.com> Signed-off-by:
Mikhail Sennikovskii <mikhail.sennikovskii@profitbricks.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim KrÄmáÅ
™ <rkrcmar@redhat.com> Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit 79e0348c ] Drivers are supposed to set correct ecc->{size,strength,bytes} before calling nand_scan_tail(), but it does not complain about ecc->total bigger than oobsize. In this case, chip->scan_bbt() crashes due to memory corruption, but it is hard to debug. It would be kind to fail it earlier with a clear message. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
Boris Brezillon authored
[ Upstream commit 4d02423e ] The GPMI driver is wrongly assuming that nand_release() can safely be called on an uninitialized/unregistered NAND device. Add a new err_nand_cleanup label in the error path and only execute if nand_scan_tail() succeeded. Note that we now call nand_cleanup() instead of nand_release() (nand_release() is actually grouping the mtd_device_unregister() and nand_cleanup() in one call) because there's no point in trying to unregister a device that has never been registered. Signed-off-by:
Marek Vasut <marek.vasut@gmail.com> Acked-by:
Han Xu <han.xu@nxp.com> Reviewed-by:
-
Maxime Ripard authored
[ Upstream commit 22662f12 ] The Allwinner Timings Controller has two, mutually exclusive, channels. When the binding has been introduced, it was assumed that there would be only a single user per channel in the system. While this is likely for the channel 0 which only connects to LCD displays, it turns out that the channel 1 can be connected to multiple controllers in the SoC (HDMI and TV encoders for example). And while the simultaneous use of HDMI and TV outputs cannot be achieved, switching from one to the other at runtime definitely sounds plausible. Add an extra property, allwinner,tcon-channel, to specify for a given endpoint which TCON channel it is connected to, while falling back to the previous mechanism if that property is missing. Acked-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Maxime Ripard authored
[ Upstream commit 49baeb07 ] The generic connectors such as hdmi-connector doesn't have any driver in, so if they are added to the component list, we will be waiting forever for a non-existing driver to probe. Add a list of the connectors we want to ignore when building our component list. Reviewed-by:
-
Alexandre Belloni authored
[ Upstream commit 8e56133e ] clk_generated_startup is called after clk_hw_register. So the first call to get_parent will not have the correct value (i.e. 0) and because this is cached, it may never be updated. Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Fixes: df70aeef ("clk: at91: add generated clock driver") Signed-off-by:
-
Gustavo A. R. Silva authored
[ Upstream commit 06d2d643 ] Add NULL check before dereferencing pointer _id_ in order to avoid a potential NULL pointer dereference. Addresses-Coverity-ID: 1397995 Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
-
NeilBrown authored
[ Upstream commit 6ea44adc ] If you attempt a TCP mount from an host that is unreachable in a way that triggers an immediate error from kernel_connect(), that error does not propagate up, instead EAGAIN is reported. This results in call_connect_status receiving the wrong error. A case that it easy to demonstrate is to attempt to mount from an address that results in ENETUNREACH, but first deleting any default route. Without this patch, the mount.nfs process is persistently runnable and is hard to kill. With this patch it exits as it should. The problem is caused by the fact that xs_tcp_force_close() eventually calls xprt_wake_pending_tasks(xprt, -EAGAIN); which causes an error return of -EAGAIN. so when xs_tcp_setup_sock() calls xprt_wake_pending_tasks(xprt, status); the status is ignored. Fixes: 4efdd92c ("SUNRPC: Remove TCP client connection reset hack") Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Vaibhav Jain authored
[ Upstream commit da96aea0 ] In function __rtc_read_alarm() its possible for an alarm time-stamp to be invalid even after replacing missing components with current time-stamp. The condition 'alarm->time.tm_year < 70' will trigger this case and will cause the call to 'rtc_tm_to_time64(&alarm->time)' return a negative value for variable t_alm. While handling alarm rollover this negative t_alm (assumed to seconds offset from '1970-01-01 00:00:00') is converted back to rtc_time via rtc_time64_to_tm() which results in this error log with seemingly garbage values: "rtc rtc0: invalid alarm value: -2-1--1041528741 2005511117:71582844:32" This error was generated when the rtc driver (rtc-opal in this case) returned an alarm time-stamp of '00-00-00 00:00:00' to indicate that the alarm is disabled. Though I have submitted a separate fix for the rtc-opal driver, this issue may potentially impact other existing/future rtc drivers. To fix this issue the patch validates the alarm time-stamp just after filling up the missing datetime components and if rtc_valid_tm() still reports it to be invalid then bails out of the function without handling the rollover. Reported-by:
Steve Best <sbest@redhat.com> Signed-off-by:
Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Signed-off-by:
-
Vaibhav Jain authored
[ Upstream commit 6dc1cf6f ] On PowerNV platform when Timed-Power-On(TPO) is disabled, read of stored TPO yields value with all date components set to '0' inside opal_get_tpo_time(). The function opal_to_tm() then converts it to an offset from year 1900 yielding alarm-time == "1900-00-01 00:00:00". This causes problems with __rtc_read_alarm() that expecting an offset from "1970-00-01 00:00:00" and returned alarm-time results in a -ve value for time64_t. Which ultimately results in this error reported in kernel logs with a seemingly garbage value: "rtc rtc0: invalid alarm value: -2-1--1041528741 2005511117:71582844:32" We fix this by explicitly handling the case of all alarm date-time components being '0' inside opal_get_tpo_time() and returning -ENOENT in such a case. This signals generic rtc that no alarm is set and it bails out from the alarm initialization flow without reporting the above error. Signed-off-by:
-
Jesse Brandeburg authored
[ Upstream commit 155b0f69 ] This patch fixes a missing line that was missed while merging, which results in a driver feature in the VF not working to enable RSS as a negotiated feature. Fixes: 43a3d9ba ("i40evf: Allow PF driver to configure RSS") Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Gary Bisson authored
[ Upstream commit 0f546b05 ] This patch is only relevant for RTC with the SQ_ALT feature which means the clock output frequency divider is stored in the weekday register. Current implementation discards the previous dividers value and clear them as soon as the time is set. Signed-off-by:
Gary Bisson <gary.bisson@boundarydevices.com> Signed-off-by:
-
Arjun Vynipadath authored
[ Upstream commit 90592b9a ] GRO is not supported by Chelsio HW when rx_csum is disabled. Update the netdev features flag when rx_csum is modified. Signed-off-by:
Arjun Vynipadath <arjun@chelsio.com> Signed-off-by:
-
Arjun Vynipadath authored
[ Upstream commit 26747211 ] Disable FW_OK flag while flashing Firmware. This will help to fix any potential mailbox timeouts during Firmware flash. Grab new devlog parameters after Firmware restart. When we FLASH new Firmware onto an adapter, the new Firmware may have the Firmware Device Log located at a different memory address or have a different size for it. Signed-off-by:
Casey Leedom <leedom@chelsio.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit f0d7ae95 ] Building the driver with CONFIG_SMP disabled results in a harmless warning: ethernet/mellanox/mlx5/core/main.c: In function 'mlx5_irq_set_affinity_hint': ethernet/mellanox/mlx5/core/main.c:615:6: error: unused variable 'irq' [-Werror=unused-variable] It's better to express the conditional compilation using IS_ENABLED() here, as that lets the compiler see what the intented use for the variable is, and that it can be silently discarded. Fixes: b665d98e ("net/mlx5: Tolerate irq_set_affinity_hint() failures") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 5f16a046 ] FUTEX_OP_OPARG_SHIFT instructs the futex code to treat the 12-bit oparg field as a shift value, potentially leading to a left shift value that is negative or with an absolute value that is significantly larger then the size of the type. UBSAN chokes with: ================================================================================ UBSAN: Undefined behaviour in ./arch/arm64/include/asm/futex.h:60:13 shift exponent -1 is negative CPU: 1 PID: 1449 Comm: syz-executor0 Not tainted 4.11.0-rc4-00005-g977eb52-dirty #11 Hardware name: linux,dummy-virt (DT) Call trace: [<ffff200008094778>] dump_backtrace+0x0/0x538 arch/arm64/kernel/traps.c:73 [<ffff200008094cd0>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228 [<ffff200008c194a8>] __dump_stack lib/dump_stack.c:16 [inline] [<ffff200008c194a8>] dump_stack+0x120/0x188 lib/dump_stack.c:52 [<ffff200008cc24b8>] ubsan_epilogue+0x18/0x98 lib/ubsan.c:164 [<ffff200008cc3098>] __ubsan_handle_shift_out_of_bounds+0x250/0x294 lib/ubsan.c:421 [<ffff20000832002c>] futex_atomic_op_inuser arch/arm64/include/asm/futex.h:60 [inline] [<ffff20000832002c>] futex_wake_op kernel/futex.c:1489 [inline] [<ffff20000832002c>] do_futex+0x137c/0x1740 kernel/futex.c:3231 [<ffff200008320504>] SYSC_futex kernel/futex.c:3281 [inline] [<ffff200008320504>] SyS_futex+0x114/0x268 kernel/futex.c:3249 [<ffff200008084770>] el0_svc_naked+0x24/0x28 ================================================================================ syz-executor1 uses obsolete (PF_INET,SOCK_PACKET) sock: process `syz-executor0' is using obsolete setsockopt SO_BSDCOMPAT This patch attempts to fix some of this by: * Making encoded_op an unsigned type, so we can shift it left even if the top bit is set. * Casting to signed prior to shifting right when extracting oparg and cmparg * Consider only the bottom 5 bits of oparg when using it as a left-shift value. Whilst I think this catches all of the issues, I'd much prefer to remove this stuff, as I think it's unused and the bugs are copy-pasted between a bunch of architectures. Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Sudip Mukherjee authored
[ Upstream commit 7e715c2d ] It is possible to update the backlight power and the brightness using the sysfs and on writing it either returns the count or if the callback function does not exist then returns the error code 'ENXIO'. We have a situation where the userspace client is writing to the sysfs to update the power and since the callback function exists the client receives the return value as count and considers the operation to be successful. That is correct as the write to the sysfs was successful. But there is no way to know if the actual operation was done or not. backlight_update_status() returns the error code if it fails. Pass that to the userspace client who is trying to update the power so that the client knows that the operation failed. Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Acked-by:
Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Arvind Yadav authored
[ Upstream commit fb9caf37 ] clk_prepare_enable() can fail here and we must check its return value. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Ivan Mikhaylov authored
[ Upstream commit 6e2f03e2 ] Prevent a kernel panic caused by unintentionally clearing TCR watchdog bits. At this point in the kernel boot, the watchdog may have already been enabled by u-boot. The original code's attempt to write to the TCR register results in an inadvertent clearing of the watchdog configuration bits, causing the 476 to reset. Signed-off-by:
Ivan Mikhaylov <ivan@de.ibm.com> Signed-off-by:
-
Miklos Szeredi authored
[ Upstream commit a082c6f6 ] Filesystems filter out extended attributes in the "trusted." domain for unprivlieged callers. Overlay calls underlying filesystem's method with elevated privs, so need to do the filtering in overlayfs too. Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit f3d3eab6 ] For ACPI devices which do not have a _PSC method, the ACPI subsys cannot query their initial state at boot, so these devices are assumed to have been put in D0 by the BIOS, but for touchscreens that is not always true. This commit adds a call to acpi_device_fix_up_power to explicitly put devices without a _PSC method into D0 state (for devices with a _PSC method it is a nop). Note we only need to do this on probe, after a resume the ACPI subsys knows the device is in D3 and will properly put it in D0. This fixes the SIS0817 i2c-hid touchscreen on a Peaq C1010 2-in-1 device failing to probe with a "hid_descr_cmd failed" error. Acked-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Florian Westphal authored
[ Upstream commit b0feacaa ] nf_ct_iterate_cleanup_net currently calls iter() callback also for conntracks on the unconfirmed list, but this is unsafe. Acesses to nf_conn are fine, but some users access the extension area in the iter() callback, but that does only work reliably for confirmed conntracks (ct->ext can be reallocated at any time for unconfirmed conntrack). The seond issue is that there is a short window where a conntrack entry is neither on the list nor in the table: To confirm an entry, it is first removed from the unconfirmed list, then insert into the table. Fix this by iterating the unconfirmed list first and marking all entries as dying, then wait for rcu grace period. This makes sure all entries that were about to be confirmed either are in the main table, or will be dropped soon. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Sai Praneeth authored
[ Upstream commit 4e52797d ] Booting kexec kernel with "efi=old_map" in kernel command line hits kernel panic as shown below. BUG: unable to handle kernel paging request at ffff88007fe78070 IP: virt_efi_set_variable.part.7+0x63/0x1b0 PGD 7ea28067 PUD 7ea2b067 PMD 7ea2d067 PTE 0 [...] Call Trace: virt_efi_set_variable() efi_delete_dummy_variable() efi_enter_virtual_mode() start_kernel() x86_64_start_reservations() x86_64_start_kernel() start_cpu() [ efi=old_map was never intended to work with kexec. The problem with using efi=old_map is that the virtual addresses are assigned from the memory region used by other kernel mappings; vmalloc() space. Potentially there could be collisions when booting kexec if something else is mapped at the virtual address we allocated for runtime service regions in the initial boot - Matt Fleming ] Since kexec was never intended to work with efi=old_map, disable runtime services in kexec if booted with efi=old_map, so that we don't panic. Tested-by:
Lee Chun-Yi <jlee@suse.com> Signed-off-by:
Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Signed-off-by:
Matt Fleming <matt@codeblueprint.co.uk> Acked-by:
Dave Young <dyoung@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ravi Shankar <ravi.v.shankar@intel.com> Cc: Ricardo Neri <ricardo.neri@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170526113652.21339-4-matt@codeblueprint.co.ukSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Firo Yang authored
[ Upstream commit fb3ce90b ] syszkaller fuzzer triggered a divide by zero, when set calibration through ioctl(). To fix it, test 'bitrate' if it is negative or 0, just return -EINVAL. Reported-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
Firo Yang <firogm@gmail.com> Signed-off-by:
-
