- 14 May, 2020 40 commits
-
-
Wei Yongjun authored
BugLink: https://bugs.launchpad.net/bugs/1878098 commit ce4e4584 upstream. Fixes the following sparse warnings: drivers/crypto/mxs-dcp.c:39:15: warning: symbol 'sha1_null_hash' was not declared. Should it be static? drivers/crypto/mxs-dcp.c:43:15: warning: symbol 'sha256_null_hash' was not declared. Should it be static? Fixes: c709eeba ("crypto: mxs-dcp - Fix SHA null hashes and output length") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ian May <ian.may@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1878098 commit 773daa3c upstream. The newly introudced ip_min_valid_pmtu variable is only used when CONFIG_SYSCTL is set: net/ipv4/route.c:135:12: error: 'ip_min_valid_pmtu' defined but not used [-Werror=unused-variable] This moves it to the other variables like it, to avoid the harmless warning. Fixes: c7272c2f ("net: ipv4: don't allow setting net.ipv4.route.min_pmtu below 68") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Nicolai Stange authored
BugLink: https://bugs.launchpad.net/bugs/1878098 commit 20b50d79 upstream. Commit 8f659a03 ("net: ipv4: fix for a race condition in raw_sendmsg") fixed the issue of possibly inconsistent ->hdrincl handling due to concurrent updates by reading this bit-field member into a local variable and using the thus stabilized value in subsequent tests. However, aforementioned commit also adds the (correct) comment that /* hdrincl should be READ_ONCE(inet->hdrincl) * but READ_ONCE() doesn't work with bit fields */ because as it stands, the compiler is free to shortcut or even eliminate the local variable at its will. Note that I have not seen anything like this happening in reality and thus, the concern is a theoretical one. However, in order to be on the safe side, emulate a READ_ONCE() on the bit-field by doing it on the local 'hdrincl' variable itself: int hdrincl = inet->hdrincl; hdrincl = READ_ONCE(hdrincl); This breaks the chain in the sense that the compiler is not allowed to replace subsequent reads from hdrincl with reloads from inet->hdrincl. Fixes: 8f659a03 ("net: ipv4: fix for a race condition in raw_sendmsg") Signed-off-by:
Nicolai Stange <nstange@suse.de> Reviewed-by:
Stefano Brivio <sbrivio@redhat.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1878098 commit 6a30abaa upstream. The commit c469652b ("ALSA: hda - Use IS_REACHABLE() for dependency on input") simplified the dependencies with IS_REACHABLE() macro, but it broke due to its incorrect usage: it should have been IS_REACHABLE(CONFIG_INPUT) instead of IS_REACHABLE(INPUT). Fixes: c469652b ("ALSA: hda - Use IS_REACHABLE() for dependency on input") Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Dmitry Monakhov authored
BugLink: https://bugs.launchpad.net/bugs/1878098 commit 4068664e upstream. Extents are cached in read_extent_tree_block(); as a result, extents are not cached for inodes with depth == 0 when we try to find the extent using ext4_find_extent(). The result of the lookup is cached in ext4_map_blocks() but is only a subset of the extent on disk. As a result, the contents of extents status cache can get very badly fragmented for certain workloads, such as a random 4k read workload. File size of /mnt/test is 33554432 (8192 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 8191: 40960.. 49151: 8192: last,eof $ perf record -e 'ext4:ext4_es_*' /root/bin/fio --name=t --direct=0 --rw=randread --bs=4k --filesize=32M --size=32M --filename=/mnt/test $ perf script | grep ext4_es_insert_extent | head -n 10 fio 131 [000] 13.975421: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [494/1) mapped 41454 status W fio 131 [000] 13.975939: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [6064/1) mapped 47024 status W fio 131 [000] 13.976467: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [6907/1) mapped 47867 status W fio 131 [000] 13.976937: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [3850/1) mapped 44810 status W fio 131 [000] 13.977440: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [3292/1) mapped 44252 status W fio 131 [000] 13.977931: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [6882/1) mapped 47842 status W fio 131 [000] 13.978376: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [3117/1) mapped 44077 status W fio 131 [000] 13.978957: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [2896/1) mapped 43856 status W fio 131 [000] 13.979474: ext4:ext4_es_insert_extent: dev 253,0 ino 12 es [7479/1) mapped 48439 status W Fix this by caching the extents for inodes with depth == 0 in ext4_find_extent(). [ Renamed ext4_es_cache_extents() to ext4_cache_extents() since this newly added function is not in extents_cache.c, and to avoid potential visual confusion with ext4_es_cache_extent(). -TYT ] Signed-off-by:
Dmitry Monakhov <dmonakhov@gmail.com> Link: https://lore.kernel.org/r/20191106122502.19986-1-dmonakhov@gmail.comSigned-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1875905Signed-off-by:
-
Samuel Neves authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit e78e5a91 upstream. In the __getcpu function, lsl is using the wrong target and destination registers. Luckily, the compiler tends to choose %eax for both variables, so it has been working so far. Fixes: a582c540 ("x86/vdso: Use RDPID in preference to LSL when available") Signed-off-by:
Samuel Neves <sneves@dei.uc.pt> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Andy Lutomirski <luto@kernel.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180901201452.27828-1-sneves@dei.uc.ptSigned-off-by:
Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by:
-
Evalds Iodzevics authored
BugLink: https://bugs.launchpad.net/bugs/1875905 On Intel it is required to do CPUID(1) before reading the microcode revision MSR. Current code in 4.4 an 4.9 relies on sync_core() to call CPUID, unfortunately on 32 bit machines code inside sync_core() always jumps past CPUID instruction as it depends on data structure boot_cpu_data witch are not populated correctly so early in boot sequence. It depends on: commit 5dedade6 ("x86/CPU: Add native CPUID variants returning a single datum") This patch is for 4.4 but also should apply to 4.9 Signed-off-by:
Evalds Iodzevics <evalds.iodzevics@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Borislav Petkov authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit 5dedade6 upstream. ... similarly to the cpuid_<reg>() variants. Signed-off-by:
Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/20170109114147.5082-2-bp@alien8.deSigned-off-by:
-
Wen Yang authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit 49c64df8 upstream. The variable 'name' is released multiple times in the error path, which may cause double free issues. This problem is avoided by adding a goto label to release the memory uniformly. And this change also makes the code a bit more cleaner. Fixes: 4f678a58 ("mtd: fix memory leaks in phram_setup") Signed-off-by:
Wen Yang <wenyang@linux.alibaba.com> Cc: Joern Engel <joern@lazybastard.org> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: linux-mtd@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200318153156.25612-1-wenyang@linux.alibaba.comSigned-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit 4da0ea71 upstream. This function is only called from lpddr_probe(). We free "lpddr" both here and in the caller, so it's a double free. The best place to free "lpddr" is in lpddr_probe() so let's delete this one. Fixes: 8dc00439 ("[MTD] LPDDR qinfo probing.") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Paul E. McKenney authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit 80c503e0 upstream. The __torture_print_stats() function in locktorture.c carefully initializes local variable "min" to statp[0].n_lock_acquired, but then compares it to statp[i].n_lock_fail. Given that the .n_lock_fail field should normally be zero, and given the initialization, it seems reasonable to display the maximum and minimum number acquisitions instead of miscomputing the maximum and minimum number of failures. This commit therefore switches from failures to acquisitions. And this turns out to be not only a day-zero bug, but entirely my own fault. I hate it when that happens! Fixes: 0af3fe1e ("locktorture: Add a lock-torture kernel module") Reported-by:
Will Deacon <will@kernel.org> Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Acked-by:
-
Stephen Rothwell authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit 3670664b upstream. ev_byte_channel_send() assumes that its third argument is a 16 byte array. Some places where it is called it may not be (or we can't easily tell if it is). Newer compilers have started producing warnings about this, so make sure we actually pass a 16 byte array. There may be more elegant solutions to this, but the driver is quite old and hasn't been updated in many years. The warnings (from a powerpc allyesconfig build) are: In file included from include/linux/byteorder/big_endian.h:5, from arch/powerpc/include/uapi/asm/byteorder.h:14, from include/asm-generic/bitops/le.h:6, from arch/powerpc/include/asm/bitops.h:250, from include/linux/bitops.h:29, from include/linux/kernel.h:12, from include/asm-generic/bug.h:19, from arch/powerpc/include/asm/bug.h:109, from include/linux/bug.h:5, from include/linux/mmdebug.h:5, from include/linux/gfp.h:5, from include/linux/slab.h:15, from drivers/tty/ehv_bytechan.c:24: drivers/tty/ehv_bytechan.c: In function ‘ehv_bc_udbg_putc’: arch/powerpc/include/asm/epapr_hcalls.h:298:20: warning: array subscript 1 is outside array bounds of ‘const char[1]’ [-Warray-bounds] 298 | r6 = be32_to_cpu(p[1]); include/uapi/linux/byteorder/big_endian.h:40:51: note: in definition of macro ‘__be32_to_cpu’ 40 | #define __be32_to_cpu(x) ((__force __u32)(__be32)(x)) | ^ arch/powerpc/include/asm/epapr_hcalls.h:298:7: note: in expansion of macro ‘be32_to_cpu’ 298 | r6 = be32_to_cpu(p[1]); | ^~~~~~~~~~~ drivers/tty/ehv_bytechan.c:166:13: note: while referencing ‘data’ 166 | static void ehv_bc_udbg_putc(char c) | ^~~~~~~~~~~~~~~~ Fixes: dcd83aaf ("tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver") Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Tested-by:
Laurentiu Tudor <laurentiu.tudor@nxp.com> [mpe: Trim warnings from change log] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200109183912.5fcb52aa@canb.auug.org.auSigned-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit d3d19d6f upstream. The "fix" struct has a 2 byte hole after ->ywrapstep and the "fix = info->fix;" assignment doesn't necessarily clear it. It depends on the compiler. The solution is just to replace the assignment with an memcpy(). Fixes: 1f5e31d7 ("fbmem: don't call copy_from/to_user() with mutex held") Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200113100132.ixpaymordi24n3av@kili.mountainSigned-off-by:
-
Adrian Huang authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit c20f3653 ] The SPA of the GCR3 table root pointer[51:31] masks 20 bits. However, this requires 21 bits (Please see the AMD IOMMU specification). This leads to the potential failure when the bit 51 of SPA of the GCR3 table root pointer is 1'. Signed-off-by:
Adrian Huang <ahuang12@lenovo.com> Fixes: 52815b75 ("iommu/amd: Add support for IOMMUv2 domain mode") Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Randy Dunlap authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit 44a52022 ] When EXT2_ATTR_DEBUG is not defined, modify the 2 debug macros to use the no_printk() macro instead of <nothing>. This fixes gcc warnings when -Wextra is used: ../fs/ext2/xattr.c:252:42: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../fs/ext2/xattr.c:258:42: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../fs/ext2/xattr.c:330:42: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../fs/ext2/xattr.c:872:45: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body] I have verified that the only object code change (with gcc 7.5.0) is the reversal of some instructions from 'cmp a,b' to 'cmp b,a'. Link: https://lore.kernel.org/r/e18a7395-61fb-2093-18e8-ed4f8cf56248@infradead.orgSigned-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Jan Kara <jack@suse.com> Cc: linux-ext4@vger.kernel.org Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Trond Myklebust authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit 862f35c9 ] If we just set the mirror count to 1 without first clearing out the mirrors, we can leak queued up requests. Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Vegard Nossum authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit af9c5d2e ] compiletime_assert() uses __LINE__ to create a unique function name. This means that if you have more than one BUILD_BUG_ON() in the same source line (which can happen if they appear e.g. in a macro), then the error message from the compiler might output the wrong condition. For this source file: #include <linux/build_bug.h> #define macro() \ BUILD_BUG_ON(1); \ BUILD_BUG_ON(0); void foo() { macro(); } gcc would output: ./include/linux/compiler.h:350:38: error: call to `__compiletime_assert_9' declared with attribute error: BUILD_BUG_ON failed: 0 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) However, it was not the BUILD_BUG_ON(0) that failed, so it should say 1 instead of 0. With this patch, we use __COUNTER__ instead of __LINE__, so each BUILD_BUG_ON() gets a different function name and the correct condition is printed: ./include/linux/compiler.h:350:38: error: call to `__compiletime_assert_0' declared with attribute error: BUILD_BUG_ON failed: 1 _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) Signed-off-by:
Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Reviewed-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by:
Daniel Santos <daniel.santos@pobox.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Ian Abbott <abbotti@mev.co.uk> Cc: Joe Perches <joe@perches.com> Link: http://lkml.kernel.org/r/20200331112637.25047-1-vegard.nossum@oracle.comSigned-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Qian Cai authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit 7e234520 ] "vm_committed_as.count" could be accessed concurrently as reported by KCSAN, BUG: KCSAN: data-race in __vm_enough_memory / percpu_counter_add_batch write to 0xffffffff9451c538 of 8 bytes by task 65879 on cpu 35: percpu_counter_add_batch+0x83/0xd0 percpu_counter_add_batch at lib/percpu_counter.c:91 __vm_enough_memory+0xb9/0x260 dup_mm+0x3a4/0x8f0 copy_process+0x2458/0x3240 _do_fork+0xaa/0x9f0 __do_sys_clone+0x125/0x160 __x64_sys_clone+0x70/0x90 do_syscall_64+0x91/0xb05 entry_SYSCALL_64_after_hwframe+0x49/0xbe read to 0xffffffff9451c538 of 8 bytes by task 66773 on cpu 19: __vm_enough_memory+0x199/0x260 percpu_counter_read_positive at include/linux/percpu_counter.h:81 (inlined by) __vm_enough_memory at mm/util.c:839 mmap_region+0x1b2/0xa10 do_mmap+0x45c/0x700 vm_mmap_pgoff+0xc0/0x130 ksys_mmap_pgoff+0x6e/0x300 __x64_sys_mmap+0x33/0x40 do_syscall_64+0x91/0xb05 entry_SYSCALL_64_after_hwframe+0x49/0xbe The read is outside percpu_counter::lock critical section which results in a data race. Fix it by adding a READ_ONCE() in percpu_counter_read_positive() which could also service as the existing compiler memory barrier. Signed-off-by:
Qian Cai <cai@lca.pw> Signed-off-by:
Marco Elver <elver@google.com> Link: http://lkml.kernel.org/r/1582302724-2804-1-git-send-email-cai@lca.pwSigned-off-by:
-
Eric Sandeen authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit c96e2b85 ] Under some circumstances we may encounter a filesystem error on a read-only block device, and if we try to save the error info to the superblock and commit it, we'll wind up with a noisy error and backtrace, i.e.: [ 3337.146838] EXT4-fs error (device pmem1p2): ext4_get_journal_inode:4634: comm mount: inode #0: comm mount: iget: illegal inode # ------------[ cut here ]------------ generic_make_request: Trying to write to read-only block-device pmem1p2 (partno 2) WARNING: CPU: 107 PID: 115347 at block/blk-core.c:788 generic_make_request_checks+0x6b4/0x7d0 ... To avoid this, commit the error info in the superblock only if the block device is writable. Reported-by:
Ritesh Harjani <riteshh@linux.ibm.com> Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Link: https://lore.kernel.org/r/4b6e774d-cc00-3469-7abb-108eb151071a@sandeen.netSigned-off-by:
-
Misono Tomohiro authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit 8605cf0e ] When dreq is allocated by nfs_direct_req_alloc(), dreq->kref is initialized to 2. Therefore we need to call nfs_direct_req_release() twice to release the allocated dreq. Usually it is called in nfs_file_direct_{read, write}() and nfs_direct_complete(). However, current code only calls nfs_direct_req_relese() once if nfs_get_lock_context() fails in nfs_file_direct_{read, write}(). So, that case would result in memory leak. Fix this by adding the missing call. Signed-off-by:
Misono Tomohiro <misono.tomohiro@jp.fujitsu.com> Signed-off-by:
-
Sowjanya Komatineni authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit 6fe38aa8 ] Tegra PMC clocks clk_out_1, clk_out_2, and clk_out_3 supported parents are osc, osc_div2, osc_div4 and extern clock. Clock driver is using incorrect parents clk_m, clk_m_div2, clk_m_div4 for PMC clocks. This patch fixes this. Tested-by:
Dmitry Osipenko <digetx@gmail.com> Reviewed-by:
Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Claudiu Beznea authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit b0ecf1c6 ] clk_hw_round_rate() may call round rate function of its parents. In case of SAM9X60 two of USB parrents are PLLA and UPLL. These clocks are controlled by clk-sam9x60-pll.c driver. The round rate function for this driver is sam9x60_pll_round_rate() which call in turn sam9x60_pll_get_best_div_mul(). In case the requested rate is not in the proper range (rate < characteristics->output[0].min && rate > characteristics->output[0].max) the sam9x60_pll_round_rate() will return a negative number to its caller (called by clk_core_round_rate_nolock()). clk_hw_round_rate() will return zero in case a negative number is returned by clk_core_round_rate_nolock(). With this, the USB clock will continue its rate computation even caller of clk_hw_round_rate() returned an error. With this, the USB clock on SAM9X60 may not chose the best parent. I detected this after a suspend/resume cycle on SAM9X60. Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lkml.kernel.org/r/1579261009-4573-2-git-send-email-claudiu.beznea@microchip.comSigned-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Frank Rowand authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit 216830d2 ] kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 2 of 5. of_unittest_platform_populate() left an elevated reference count for grandchild nodes (which are platform devices). Fix the platform device reference counts so that the memory will be freed. Fixes: fb2caa50 ("of/selftest: add testcase for nodes with same name and address") Reported-by:
Erhard F. <erhard_f@mailbox.org> Signed-off-by:
Frank Rowand <frank.rowand@sony.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Rob Herring authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit bd82bbf3 ] The ref counting is broken for OF_DYNAMIC when sysfs is disabled because the kobject initialization is skipped. Only the properties add/remove/update should be skipped for !SYSFS config. Tested-by:
Nicolas Pitre <nico@linaro.org> Reviewed-by:
Frank Rowand <frowand.list@gmail.com> Acked-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Chris Lew authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit a216000f ] Endianness can vary in the system, add le32_to_cpu when comparing partition sizes from smem. Signed-off-by:
Chris Lew <clew@codeaurora.org> Acked-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Andy Gross <andy.gross@linaro.org> Signed-off-by:
-
Mohit Aggarwal authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit 83220bf3 ] In order to set time in rtc, need to disable rtc hw before writing into rtc registers. Also fixes disabling of alarm while setting rtc time. Signed-off-by:
Mohit Aggarwal <maggarwa@codeaurora.org> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Dedy Lansky authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit 3d6b7272 ] wil_err inside wil_rx_refill can flood the log buffer. Replace it with wil_err_ratelimited. Signed-off-by:
Dedy Lansky <dlansky@codeaurora.org> Signed-off-by:
Maya Erez <merez@codeaurora.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Subhash Jadavani authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit 69a6fff0 ] UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION is only applicable for QCOM UFS host controller version 2.x.y and this has been fixed from version 3.x.y onwards, hence this change removes this quirk for version 3.x.y onwards. [mkp: applied by hand] Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
Asutosh Das <asutoshd@codeaurora.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Dedy Lansky authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit 6d9eb7eb ] For negative temperatures, "temp" debugfs is showing wrong values. Use signed types so proper calculations is done for sub zero temperatures. Signed-off-by:
-
Hamad Kadmany authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit 6ccae584 ] Firmware ready event may take longer than current timeout in some scenarios, for example with multiple RFs connected where each requires an initial calibration. Increase the timeout to support these scenarios. Signed-off-by:
Hamad Kadmany <hkadmany@codeaurora.org> Signed-off-by:
-
Joe Moriarty authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit 22a07038 upstream. The Parfait (version 2.1.0) static code analysis tool found the following NULL pointer derefernce problem. - drivers/gpu/drm/drm_dp_mst_topology.c The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt() could result in a NULL pointer being returned to port->mstb due to a failure to allocate memory for port->mstb. Signed-off-by:
Joe Moriarty <joe.moriarty@oracle.com> Reviewed-by:
Steven Sistare <steven.sistare@oracle.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180212195144.98323-3-joe.moriarty@oracle.comSigned-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit 864eb1af upstream. Clang warns when multiple pairs of parentheses are used for a single conditional statement. drivers/video/fbdev/sis/init301.c:851:42: warning: equality comparison with extraneous parentheses [-Wparentheses-equality] } else if((SiS_Pr->SiS_IF_DEF_LVDS == 1) /* || ~~~~~~~~~~~~~~~~~~~~~~~~^~~~ drivers/video/fbdev/sis/init301.c:851:42: note: remove extraneous parentheses around the comparison to silence this warning } else if((SiS_Pr->SiS_IF_DEF_LVDS == 1) /* || ~ ^ ~ drivers/video/fbdev/sis/init301.c:851:42: note: use '=' to turn this equality comparison into an assignment } else if((SiS_Pr->SiS_IF_DEF_LVDS == 1) /* || ^~ = 1 warning generated. Remove the parentheses and while we're at it, clean up the commented code, which has been here since the beginning of git history. Link: https://github.com/ClangBuiltLinux/linux/issues/118Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Cc: Thomas Winischhofer <thomas@winischhofer.net> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit 25faa4bd upstream. At the error path of the firmware loading error, the driver tries to release the card object and set NULL to drvdata. This may be referred badly at the possible PM action, as the driver itself is still bound and the PM callbacks read the card object. Instead, we continue the probing as if it were no option set. This is often a better choice than the forced abort, too. Fixes: 5cb543db ("ALSA: hda - Deferred probing with request_firmware_nowait()") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Link: https://lore.kernel.org/r/20200413082034.25166-2-tiwai@suse.deSigned-off-by:
-
Li Bin authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit 849f8583 upstream. If the dxfer_len is greater than 256M then the request is invalid and we need to call sg_remove_request in sg_common_write. Link: https://lore.kernel.org/r/1586777361-17339-1-git-send-email-huawei.libin@huawei.com Fixes: f930c704 ("scsi: sg: only check for dxfer_len greater than 256M") Acked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
Li Bin <huawei.libin@huawei.com> Signed-off-by:
-
Xiao Yang authored
tracing: Fix the race between registering 'snapshot' event trigger and triggering 'snapshot' operation BugLink: https://bugs.launchpad.net/bugs/1875905 commit 0bbe7f71 upstream. Traced event can trigger 'snapshot' operation(i.e. calls snapshot_trigger() or snapshot_count_trigger()) when register_snapshot_trigger() has completed registration but doesn't allocate buffer for 'snapshot' event trigger. In the rare case, 'snapshot' operation always detects the lack of allocated buffer so make register_snapshot_trigger() allocate buffer first. trigger-snapshot.tc in kselftest reproduces the issue on slow vm: ----------------------------------------------------------- cat trace ... ftracetest-3028 [002] .... 236.784290: sched_process_fork: comm=ftracetest pid=3028 child_comm=ftracetest child_pid=3036 <...>-2875 [003] .... 240.460335: tracing_snapshot_instance_cond: *** SNAPSHOT NOT ALLOCATED *** <...>-2875 [003] .... 240.460338: tracing_snapshot_instance_cond: *** stopping trace here! *** ----------------------------------------------------------- Link: http://lkml.kernel.org/r/20200414015145.66236-1-yangx.jy@cn.fujitsu.com Cc: stable@vger.kernel.org Fixes: 93e31ffb ("tracing: Add 'snapshot' event trigger command") Signed-off-by:
Xiao Yang <yangx.jy@cn.fujitsu.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Borislav Petkov authored
BugLink: https://bugs.launchpad.net/bugs/1875905 The fast SYSCALL exit path returns with SYSRET to userspace after verifying that there's no pending work. MDS mitigation mandates that CPU buffers must be cleared on transition from kernel to userspace so do that here too. Signed-off-by:
-
Jim Mattson authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit 396d2e87 upstream. The host reports support for the synthetic feature X86_FEATURE_SSBD when any of the three following hardware features are set: CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] CPUID.80000008H:EBX.AMD_SSBD[bit 24] CPUID.80000008H:EBX.VIRT_SSBD[bit 25] Either of the first two hardware features implies the existence of the IA32_SPEC_CTRL MSR, but CPUID.80000008H:EBX.VIRT_SSBD[bit 25] does not. Therefore, CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] should only be set in the guest if CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] or CPUID.80000008H:EBX.AMD_SSBD[bit 24] is set on the host. Fixes: 0c54914d ("KVM: x86: use Intel speculation bugs and features as derived in generic x86 code") Signed-off-by:
Jim Mattson <jmattson@google.com> Reviewed-by:
Jacob Xu <jacobhxu@google.com> Reviewed-by:
Peter Shier <pshier@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Reported-by:
Eric Biggers <ebiggers@kernel.org> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> [bwh: Backported to 4.x: adjust indentation] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Goldwyn Rodrigues authored
BugLink: https://bugs.launchpad.net/bugs/1875905 [ Upstream commit 7690e253 ] One can crash dm-flakey by specifying more feature arguments than the number of features supplied. Checking for null in arg_name avoids this. dmsetup create flakey-test --table "0 66076080 flakey /dev/sdb9 0 0 180 2 drop_writes" Signed-off-by:
Goldwyn Rodrigues <rgoldwyn@suse.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Jan Kara authored
BugLink: https://bugs.launchpad.net/bugs/1875905 commit 801674f3 upstream. We do not want to create initialized extents beyond end of file because for e2fsck it is impossible to distinguish them from a case of corrupted file size / extent tree and so it complains like: Inode 12, i_size is 147456, should be 163840. Fix? no Code in ext4_ext_convert_to_initialized() and ext4_split_convert_extents() try to make sure it does not create initialized extents beyond inode size however they check against inode->i_size which is wrong. They should instead check against EXT4_I(inode)->i_disksize which is the current inode size on disk. That's what e2fsck is going to see in case of crash before all dirty data is written. This bug manifests as generic/456 test failure (with recent enough fstests where fsx got fixed to properly pass FALLOC_KEEP_SIZE_FL flags to the kernel) when run with dioread_lock mount option. CC: stable@vger.kernel.org Fixes: 21ca087a ("ext4: Do not zero out uninitialized extents beyond i_size") Reviewed-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
-
