- 03 Dec, 2019 40 commits
-
-
Michael Ellerman authored
BugLink: https://bugs.launchpad.net/bugs/1853142 commit af2e8c68 upstream. On some systems that are vulnerable to Spectre v2, it is up to software to flush the link stack (return address stack), in order to protect against Spectre-RSB. When exiting from a guest we do some house keeping and then potentially exit to C code which is several stack frames deep in the host kernel. We will then execute a series of returns without preceeding calls, opening up the possiblity that the guest could have poisoned the link stack, and direct speculative execution of the host to a gadget of some sort. To prevent this we add a flush of the link stack on exit from a guest. Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> [dja: backport to v4.4, drop P9 support] Signed-off-by:
Daniel Axtens <dja@axtens.net> CVE-2019-18660 Signed-off-by:
Benjamin M Romer <benjamin.romer@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Sultan Alsawaf <sultan.alsawaf@canonical.com> Signed-off-by:
-
Michael Ellerman authored
BugLink: https://bugs.launchpad.net/bugs/1853142 commit 39e72bf9 upstream. In commit ee13cb24 ("powerpc/64s: Add support for software count cache flush"), I added support for software to flush the count cache (indirect branch cache) on context switch if firmware told us that was the required mitigation for Spectre v2. As part of that code we also added a software flush of the link stack (return address stack), which protects against Spectre-RSB between user processes. That is all correct for CPUs that activate that mitigation, which is currently Power9 Nimbus DD2.3. What I got wrong is that on older CPUs, where firmware has disabled the count cache, we also need to flush the link stack on context switch. To fix it we create a new feature bit which is not set by firmware, which tells us we need to flush the link stack. We set that when firmware tells us that either of the existing Spectre v2 mitigations are enabled. Then we adjust the patching code so that if we see that feature bit we enable the link stack flush. If we're also told to flush the count cache in software then we fall through and do that also. On the older CPUs we don't need to do do the software count cache flush, firmware has disabled it, so in that case we patch in an early return after the link stack flush. The naming of some of the functions is awkward after this patch, because they're called "count cache" but they also do link stack. But we'll fix that up in a later commit to ease backporting. This is the fix for CVE-2019-18660. Reported-by:
Anthony Steinhauser <asteinhauser@google.com> Fixes: ee13cb24 ("powerpc/64s: Add support for software count cache flush") Cc: stable@vger.kernel.org # v4.4+ Signed-off-by:
-
Christopher M. Riedl authored
BugLink: https://bugs.launchpad.net/bugs/1853142 commit d8f0e0b0 upstream. Add support for disabling the kernel implemented spectre v2 mitigation (count cache flush on context switch) via the nospectre_v2 and mitigations=off cmdline options. Suggested-by:
Christopher M. Riedl <cmr@informatik.wtf> Reviewed-by:
Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by:
-
Gerald Yang authored
BugLink: https://bugs.launchpad.net/bugs/1848481 Intel's VF drivers such as igbvf and ixgbevf are already available in generic. It makes sense to add i40evf especially for SR-IOV enabled clouds with Intel X710/XXV710/XL710. The module was renamed from i40evf to iavf since kernel 4.20, so there will be a separate SRU for other series Signed-off-by:
Gerald Yang <gerald.yang@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Current default non-adaptive tx interrupt moderation interval is 196 us. This commit sets it to 0, which is much more sensible as a default value. It can be modified using ethtool -C. Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Reference: https://lore.kernel.org/netdev/1572868728-5211-1-git-send-email-akiyano@amazon.com/Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
Khaled Elmously <khalid.elmously@canonical.com> Acked-by:
Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Issue 1: -------- Reproduction steps: 1. sudo ethtool -C eth0 rx-usecs 128 2. sudo ethtool -C eth0 adaptive-rx on 3. sudo ethtool -C eth0 adaptive-rx off 4. ethtool -c eth0 expected output: rx-usecs 128 actual output: rx-usecs 0 Reason for issue: In stage 3, ethtool userspace calls first the ena_get_coalesce() handler to get the current value of all properties, and then the ena_set_coalesce() handler. When ena_get_coalesce() is called the adaptive interrupt moderation is still on. There is an if in the code that returns the rx_coalesce_usecs only if the adaptive interrupt moderation is off. And since it is still on, rx_coalesce_usecs is not set, meaning it stays 0. Solution to issue: Remove this if static interrupt moderation intervals have nothing to do with dynamic ones. Issue 2: -------- Reproduction steps: 1. sudo ethtool -C eth0 rx-usecs 128 2. sudo ethtool -C eth0 adaptive-rx on 3. sudo ethtool -C eth0 rx-usecs 128 4. ethtool -c eth0 expected output: rx-usecs 128 actual output: rx-usecs 0 Reason for issue: In stage 3, when ena_set_coalesce() is called, the handler tests if rx adaptive interrupt moderation is on, and if it is, it returns before getting to the part in the function that sets the rx non-adaptive interrupt moderation interval. Solution to issue: Remove the return from the function when rx adaptive interrupt moderation is on. Additional small fixes in this commit: -------------------------------------- 1. Remove 2 unnecessary comments. 2. Remove 4 unnecesary "{}" in single row if statements. 3. Reorder ena_set_coalesce() to make sense. 4. Change the names of ena_update_tx/rx_rings_intr_moderation() functions to ena_update_tx/rx_rings_nonadaptive_intr_moderation() for clarity. Signed-off-by:
-
Mao Wenan authored
BugLink: https://bugs.launchpad.net/bugs/1853180 If CONFIG_ENA_ETHERNET=y and CONFIG_DIMLIB=n, below erros can be found: drivers/net/ethernet/amazon/ena/ena_netdev.o: In function `ena_dim_work': ena_netdev.c:(.text+0x21cc): undefined reference to `net_dim_get_rx_moderation' ena_netdev.c:(.text+0x21cc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `net_dim_get_rx_moderation' drivers/net/ethernet/amazon/ena/ena_netdev.o: In function `ena_io_poll': ena_netdev.c:(.text+0x7bd4): undefined reference to `net_dim' ena_netdev.c:(.text+0x7bd4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `net_dim' After commit 282faf61 ("net: ena: switch to dim algorithm for rx adaptive interrupt moderation"), it introduces dim algorithm, which configured by CONFIG_DIMLIB. So, this patch is to select DIMLIB for ENA_ETHERNET. Fixes: 282faf61 ("net: ena: switch to dim algorithm for rx adaptive interrupt moderation") Signed-off-by:
Mao Wenan <maowenan@huawei.com> Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> (cherry picked from commit ff04cfba) Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 ena_dev->intr_moder_rx/tx_interval save the intervals received from the user after dividing them by ena_dev->intr_delay_resolution. Therefore when intr_delay_resolution changes, the code needs to first mutiply intr_moder_rx/tx_interval by the previous intr_delay_resolution to get the value originally given by the user, and only then divide it by the new intr_delay_resolution. Current code does not first multiply intr_moder_rx/tx_interval by the old intr_delay_resolution. This commit fixes it. Also initialize ena_dev->intr_delay_resolution to be 1. Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 79226cea) Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Nonadaptive interrupt moderation intervals are assigned the value set by the user in ethtool -C divided by ena_dev->intr_delay_resolution. Therefore when the user tries to get the nonadaptive interrupt moderation intervals with ethtool -c the code needs to multiply the saved value by ena_dev->intr_delay_resolution. The current code erroneously divides instead of multiplying in ethtool -c. This patch fixes this. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Current implementation always updates the interrupt register with the smoothed_interval of the rx_ring. However this should be done only in case of adaptive interrupt moderation. If non-adaptive interrupt moderation is used, the non-adaptive interrupt moderation interval should be used. This commit fixes that. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Remove previous implementation of adaptive rx interrupt moderation from ena_com files. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Deleted unused 4 fields from struct ena_adapter and their only user ena_restore_ethtool_params(). Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 1. Out of the fields {per_napi_bytes, per_napi_packets} in struct ena_ring, only rx_ring->per_napi_packets are used to determine if napi did work for dim. This commit removes all other uses of these fields. 2. Remove ena_ring->moder_tbl_idx, which is not used by dim. 3. Remove all calls to ena_com_destroy_interrupt_moderation(), since all it did was to destroy the interrupt moderation table, which is removed as part of removing old interrupt moderation code. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Remove code duplication in: ena_com_update_nonadaptive_moderation_interval_tx() ena_com_update_nonadaptive_moderation_interval_rx() functions. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Add driver_supported_features to host_host info which is a new API used to communicate to the device which features are supported by the driver. Add the interrupt_moderation bit to host_info->driver_supported_features and enable it to signal the device that this driver supports interrupt moderation properly. Reserved bits are for features implemented in the future Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 1. Remove old adaptive interrupt moderation code from set/get_coalesce() 2. Add ena_update_rx_rings_intr_moderation() function for updating nonadaptive interrupt moderation intervals similarly to ena_update_tx_rings_intr_moderation(). 3. Remove checks of multiple unsupported received interrupt coalescing parameters. This makes code cleaner and cancels the need to update it every time a new coalescing parameter is invented. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Use the dim library for the rx adaptive interrupt moderation implementation Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Add intr_moder_rx_interval to struct ena_com_dev and use it as the location where the interrupt moderation rx interval is saved, instead of the interrupt moderation table. This is done as a first step before removing the old interrupt moderation code. Signed-off-by:
-
Netanel Belgazal authored
BugLink: https://bugs.launchpad.net/bugs/1853180 Fixing a bug that the driver does not unmask the IO interrupts in ndo_open(): occasionally, the MSI-X interrupt (for one or more IO queues) can be masked when ndo_close() was called. If that is followed by ndo open(), then the MSI-X will be still masked so no interrupt will be received by the driver. Fixes: 1738cd3e ("Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
Netanel Belgazal <netanel@amazon.com> Signed-off-by:
-
Kamal Mostafa authored
BugLink: https://bugs.launchpad.net/bugs/1852637 Use dimlib.o (vs. dim.o) as the interim library object filename to avoid a clash with the actual dim.c which manifests as: make[2]: Circular lib/dim/dim.o <- lib/dim/dim.o dependency dropped. Signed-off-by:
Andrea Righi <andrea.righi@canonical.com> Signed-off-by:
-
Kamal Mostafa authored
BugLink: https://bugs.launchpad.net/bugs/1852637 Import DIMLIB (lib/dim/) from mainline v5.3 as of commit f8be17b8 ("lib/dim: Fix -Wunused-const-variable warnings"). Signed-off-by:
-
Kamal Mostafa authored
BugLink: https://bugs.launchpad.net/bugs/1852637Signed-off-by:
-
Masahiro Yamada authored
BugLink: https://bugs.launchpad.net/bugs/1852637 This macro is useful to avoid link error on 32-bit systems. We have the same definition in two drivers, so move it to include/linux/kernel.h While we are here, refactor DIV_ROUND_UP_ULL() by using DIV_ROUND_DOWN_ULL(). Link: http://lkml.kernel.org/r/1500945156-12907-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Mark Brown <broonie@kernel.org> Cc: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Marek Vasut <marek.vasut@gmail.com> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Richard Weinberger <richard@nod.at> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (backported from commit 604df322) Signed-off-by:
-
Chris Wilson authored
BugLink: https://bugs.launchpad.net/bugs/1852637 net_dim.h has a rather useful extension to BITS_PER_BYTE to compute the number of bits in a type (BITS_PER_BYTE * sizeof(T)), so promote the macro to bitops.h, alongside BITS_PER_BYTE, for wider usage. Link: http://lkml.kernel.org/r/20180706094458.14116-1-chris@chris-wilson.co.ukSigned-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Andy Gospodarek <gospo@broadcom.com> Cc: David S. Miller <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1851623 Although we may have multiple fonts in kernel, the small 8x16 font is chosen as default usually unless user specify the boot option. This is suboptimal for monitors with high resolutions. This patch tries to assign a bigger font for such a high resolution by calculating some penalty value. This won't change anything for a standard monitor like Full HD (1920x1080), but for a high res monitor like UHD 4K, a bigger font like TER16x32 will be chosen once when enabled in Kconfig. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit dfd19a50) Signed-off-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1851623 Fix indentation, spaces, and move EXPORT_SYMBOL line to the appropriate place as a preliminary work. No actual code change. Signed-off-by:
-
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1853881 Ignore: yes Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1853881Signed-off-by:
-
Pavel Tatashin authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 94bb804e upstream. A number of our uaccess routines ('__arch_clear_user()' and '__arch_copy_{in,from,to}_user()') fail to re-enable PAN if they encounter an unhandled fault whilst accessing userspace. For CPUs implementing both hardware PAN and UAO, this bug has no effect when both extensions are in use by the kernel. For CPUs implementing hardware PAN but not UAO, this means that a kernel using hardware PAN may execute portions of code with PAN inadvertently disabled, opening us up to potential security vulnerabilities that rely on userspace access from within the kernel which would usually be prevented by this mechanism. In other words, parts of the kernel run the same way as they would on a CPU without PAN implemented/emulated at all. For CPUs not implementing hardware PAN and instead relying on software emulation via 'CONFIG_ARM64_SW_TTBR0_PAN=y', the impact is unfortunately much worse. Calling 'schedule()' with software PAN disabled means that the next task will execute in the kernel using the page-table and ASID of the previous process even after 'switch_mm()', since the actual hardware switch is deferred until return to userspace. At this point, or if there is a intermediate call to 'uaccess_enable()', the page-table and ASID of the new process are installed. Sadly, due to the changes introduced by KPTI, this is not an atomic operation and there is a very small window (two instructions) where the CPU is configured with the page-table of the old task and the ASID of the new task; a speculative access in this state is disastrous because it would corrupt the TLB entries for the new task with mappings from the previous address space. As Pavel explains: | I was able to reproduce memory corruption problem on Broadcom's SoC | ARMv8-A like this: | | Enable software perf-events with PERF_SAMPLE_CALLCHAIN so userland's | stack is accessed and copied. | | The test program performed the following on every CPU and forking | many processes: | | unsigned long *map = mmap(NULL, PAGE_SIZE, PROT_READ|PROT_WRITE, | MAP_SHARED | MAP_ANONYMOUS, -1, 0); | map[0] = getpid(); | sched_yield(); | if (map[0] != getpid()) { | fprintf(stderr, "Corruption detected!"); | } | munmap(map, PAGE_SIZE); | | From time to time I was getting map[0] to contain pid for a | different process. Ensure that PAN is re-enabled when returning after an unhandled user fault from our uaccess routines. Cc: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Tested-by:
Pavel Tatashin <pasha.tatashin@soleen.com> [will: rewrote commit message] [will: backport for 4.4.y stable kernels] Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Huibin Hong authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit dd8fd2cb ] The rxconf and txconf structs are allocated on the stack, so make sure we zero them before filling out the relevant fields. Signed-off-by:
Huibin Hong <huibin.hong@rock-chips.com> Signed-off-by:
Emil Renner Berthing <kernel@esmil.dk> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Felix Fietkau authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 80df9be6 ] Fixes a harmless underflow issue when CCK rates are actively being used Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Thierry Reding authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 9f67f758 ] Probe deferrals aren't actual errors, so silence the error message in case the PWM cannot yet be acquired. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Timothy E Baldwin authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit f18aef74 ] On at least x86 and ARM64, and as documented in the ptrace man page a skipped system call will still cause a syscall exit ptrace stop. Previous to this commit 32-bit ARM did not, resulting in strace being confused when seccomp skips system calls. This change also impacts programs that use ptrace to skip system calls. Fixes: ad75b514 ("ARM: 7579/1: arch/allow a scno of -1 to not cause a SIGILL") Signed-off-by:
Timothy E Baldwin <T.E.Baldwin99@members.leeds.ac.uk> Signed-off-by:
Eugene Syromyatnikov <evgsyr@gmail.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Tested-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Trent Piepho authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 605b3bec ] spidev will make a big fuss if a device tree node binds a device by using "spidev" as the node's compatible property. However, the logic for this isn't looking for "spidev" in the compatible, but rather checking that the device is NOT compatible with spidev's list of devices. This causes a false positive if a device not named "rohm,dh2228fv", etc. binds to spidev, even if a means other than putting "spidev" in the device tree was used. E.g., the sysfs driver_override attribute. Signed-off-by:
Trent Piepho <tpiepho@impinj.com> Reviewed-by:
Jan Kundrát <jan.kundrat@cesnet.cz> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Marek Vasut authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 70728c29 ] The priv->data->set can be NULL while flags contains GPIO_SYSCON_FEAT_OUT and chip->set is valid pointer. This happens in case the controller uses the default GPIO setter. Always use chip->set to access the setter to avoid possible NULL pointer dereferencing. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Bjorn Helgaas authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 51fbf14f ] The only use of KEXEC_BACKUP_SRC_END is as an argument to walk_system_ram_res(): int crash_load_segments(struct kimage *image) { ... walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END, image, determine_backup_region); walk_system_ram_res() expects "start, end" arguments that are inclusive, i.e., the range to be walked includes both the start and end addresses. KEXEC_BACKUP_SRC_END was previously defined as (640 * 1024UL), which is the first address *past* the desired 0-640KB range. Define KEXEC_BACKUP_SRC_END as (640 * 1024UL - 1) so the KEXEC_BACKUP_SRC region is [0-0x9ffff], not [0-0xa0000]. Fixes: dd5f7260 ("kexec: support for kexec on panic using new system call") Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Borislav Petkov <bp@suse.de> CC: "H. Peter Anvin" <hpa@zytor.com> CC: Andrew Morton <akpm@linux-foundation.org> CC: Brijesh Singh <brijesh.singh@amd.com> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Ingo Molnar <mingo@redhat.com> CC: Lianbo Jiang <lijiang@redhat.com> CC: Takashi Iwai <tiwai@suse.de> CC: Thomas Gleixner <tglx@linutronix.de> CC: Tom Lendacky <thomas.lendacky@amd.com> CC: Vivek Goyal <vgoyal@redhat.com> CC: baiyaowei@cmss.chinamobile.com CC: bhe@redhat.com CC: dan.j.williams@intel.com CC: dyoung@redhat.com CC: kexec@lists.infradead.org Link: http://lkml.kernel.org/r/153805811578.1157.6948388946904655969.stgit@bhelgaas-glaptop.roam.corp.google.comSigned-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 32ae5920 ] Shifting the u8 value[3] by an int can lead to sign-extension overflow. For example, if value[3] is 0xff and the shift is 24 then it is promoted to int and then the top bit is sign-extended so that all upper 32 bits are set. Fix this by casting value[3] to a u32 before the shift. Detected by CoverityScan, CID#1016522 ("Unintended sign extension") Fixes: e0d3bafd ("V4L/DVB (10954): Add cx231xx USB driver") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Tim Smith authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 1eb8d738 ] Flushing the workqueue can cause operations to happen which might call gfs2_log_reserve(), or get stuck waiting for locks taken by such operations. gfs2_log_reserve() can io_schedule(). If this happens, it will never wake because the only thing which can wake it is gfs2_logd() which was already stopped. This causes umount of a gfs2 filesystem to wedge permanently if, for example, the umount immediately follows a large delete operation. When this occured, the following stack trace was obtained from the umount command [<ffffffff81087968>] flush_workqueue+0x1c8/0x520 [<ffffffffa0666e29>] gfs2_make_fs_ro+0x69/0x160 [gfs2] [<ffffffffa0667279>] gfs2_put_super+0xa9/0x1c0 [gfs2] [<ffffffff811b7edf>] generic_shutdown_super+0x6f/0x100 [<ffffffff811b7ff7>] kill_block_super+0x27/0x70 [<ffffffffa0656a71>] gfs2_kill_sb+0x71/0x80 [gfs2] [<ffffffff811b792b>] deactivate_locked_super+0x3b/0x70 [<ffffffff811b79b9>] deactivate_super+0x59/0x60 [<ffffffff811d2998>] cleanup_mnt+0x58/0x80 [<ffffffff811d2a12>] __cleanup_mnt+0x12/0x20 [<ffffffff8108c87d>] task_work_run+0x7d/0xa0 [<ffffffff8106d7d9>] exit_to_usermode_loop+0x73/0x98 [<ffffffff81003961>] syscall_return_slowpath+0x41/0x50 [<ffffffff815a594c>] int_ret_from_sys_call+0x25/0x8f [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by:
Tim Smith <tim.smith@citrix.com> Signed-off-by:
Mark Syms <mark.syms@citrix.com> Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
-
Wenwen Wang authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit a26ac6c1 ] In isif_probe(), there is a while loop to get the ISIF base address and linearization table0 and table1 address. In the loop body, the function platform_get_resource() is called to get the resource. If platform_get_resource() returns NULL, the loop is terminated and the execution goes to 'fail_nobase_res'. Suppose the loop is terminated at the first iteration because platform_get_resource() returns NULL and the execution goes to 'fail_nobase_res'. Given that there is another while loop at 'fail_nobase_res' and i equals to 0, one iteration of the second while loop will be executed. However, the second while loop does not check the return value of platform_get_resource(). This can cause a NULL pointer dereference bug if the return value is a NULL pointer. This patch avoids the above issue by adding a check in the second while loop after the call to platform_get_resource(). Signed-off-by:
Wenwen Wang <wang6495@umn.edu> Signed-off-by:
-
He Zhe authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit e6fe3e5b ] The current printk() is ready to handle log buffer size up to 2G. Give an explicit error for users who want to use larger log buffer. Also fix printk formatting to show the 2G as a positive number. Link: http://lkml.kernel.org/r/20181008135916.gg4kkmoki5bgtco5@pathway.suse.cz Cc: rostedt@goodmis.org Cc: linux-kernel@vger.kernel.org Suggested-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by:
He Zhe <zhe.he@windriver.com> Reviewed-by:
Petr Mladek <pmladek@suse.com> Signed-off-by:
-
