- 14 May, 2020 40 commits
-
-
Geert Uytterhoeven authored
BugLink: https://bugs.launchpad.net/bugs/1878098 [ Upstream commit d5a3c7a4 ] Runtime PM should be enabled before calling pwmchip_add(), as PWM users can appear immediately after the PWM chip has been added. Likewise, Runtime PM should always be disabled after the removal of the PWM chip, even if the latter failed. Fixes: 99b82abb ("pwm: Add Renesas TPU PWM driver") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Ian May <ian.may@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Cornelia Huck authored
BugLink: https://bugs.launchpad.net/bugs/1878098 [ Upstream commit 05ce3e53 ] The common I/O layer delays the ADD uevent for subchannels and delegates generating this uevent to the individual subchannel drivers. The io_subchannel driver will do so when the associated ccw_device has been registered -- but unconditionally, so more ADD uevents will be generated if a subchannel has been unbound from the io_subchannel driver and later rebound. To fix this, only generate the ADD event if uevents were still suppressed for the device. Fixes: fa1a8c23 ("s390: cio: Delay uevents for subchannels") Message-Id: <20200327124503.9794-2-cohuck@redhat.com> Reported-by:
Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by:
Peter Oberparleiter <oberpar@linux.ibm.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1878098 [ Upstream commit 89163f93 ] If seq_file .next function does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Waiman Long <longman@redhat.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Ingo Molnar <mingo@redhat.com> Cc: NeilBrown <neilb@suse.com> Cc: Peter Oberparleiter <oberpar@linux.ibm.com> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/b7a20945-e315-8bb0-21e6-3875c14a8494@virtuozzo.comSigned-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1878098 [ Upstream commit f4d74ef6 ] If seq_file .next function does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283Signed-off-by:
-
Hans de Goede authored
BugLink: https://bugs.launchpad.net/bugs/1878098 [ Upstream commit 81630dc0 ] sst_send_slot_map() uses sst_fill_and_send_cmd_unlocked() because in some places it is called with the drv->lock mutex already held. So it must always be called with the mutex locked. This commit adds missing locking in the sst_set_be_modules() code-path. Fixes: 24c8d141 ("ASoC: Intel: mrfld: add DSP core controls") Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200402185359.3424-1-hdegoede@redhat.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Wu Bo authored
BugLink: https://bugs.launchpad.net/bugs/1878098 [ Upstream commit 13e60d3b ] If the daemon is restarted or crashes while logging out of a session, the unbind session event sent by the kernel is not processed and is lost. When the daemon starts again, the session can't be unbound because the daemon is waiting for the event message. However, the kernel has already logged out and the event will not be resent. When iscsid restart is complete, logout session reports error: Logging out of session [sid: 6, target: iqn.xxxxx, portal: xx.xx.xx.xx,3260] iscsiadm: Could not logout of [sid: 6, target: iscsiadm -m node iqn.xxxxx, portal: xx.xx.xx.xx,3260]. iscsiadm: initiator reported error (9 - internal error) iscsiadm: Could not logout of all requested sessions Make sure the unbind event is emitted. [mkp: commit desc and applied by hand since patch was mangled] Link: https://lore.kernel.org/r/4eab1771-2cb3-8e79-b31c-923652340e99@huawei.comReviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Wu Bo <wubo40@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Geert Uytterhoeven authored
BugLink: https://bugs.launchpad.net/bugs/1878098 [ Upstream commit 1451a3ee ] Runtime PM should be enabled before calling pwmchip_add(), as PWM users can appear immediately after the PWM chip has been added. Likewise, Runtime PM should be disabled after the removal of the PWM chip. Fixes: ed6c1476 ("pwm: Add support for R-Car PWM Timer") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Yan, Zheng authored
BugLink: https://bugs.launchpad.net/bugs/1878098 [ Upstream commit 0aa971b6 ] 1. try_get_cap_refs() fails to get caps and finds that mds_wanted does not include what it wants. It returns -ESTALE. 2. ceph_get_caps() calls ceph_renew_caps(). ceph_renew_caps() finds that inode has cap, so it calls ceph_check_caps(). 3. ceph_check_caps() finds that issued caps (without checking if it's stale) already includes caps wanted by open file, so it skips updating wanted caps. Above events can cause an infinite loop inside ceph_get_caps(). Signed-off-by:
"Yan, Zheng" <zyan@redhat.com> Reviewed-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Qiujun Huang authored
BugLink: https://bugs.launchpad.net/bugs/1878098 [ Upstream commit c6d50296 ] Return the error returned by ceph_mdsc_do_request(). Otherwise, r_target_inode ends up being NULL this ends up returning ENOENT regardless of the error. Signed-off-by:
Qiujun Huang <hqjagain@gmail.com> Reviewed-by:
-
James Smart authored
BugLink: https://bugs.launchpad.net/bugs/1878098 [ Upstream commit 38503943 ] The following kasan bug was called out: BUG: KASAN: slab-out-of-bounds in lpfc_unreg_login+0x7c/0xc0 [lpfc] Read of size 2 at addr ffff889fc7c50a22 by task lpfc_worker_3/6676 ... Call Trace: dump_stack+0x96/0xe0 ? lpfc_unreg_login+0x7c/0xc0 [lpfc] print_address_description.constprop.6+0x1b/0x220 ? lpfc_unreg_login+0x7c/0xc0 [lpfc] ? lpfc_unreg_login+0x7c/0xc0 [lpfc] __kasan_report.cold.9+0x37/0x7c ? lpfc_unreg_login+0x7c/0xc0 [lpfc] kasan_report+0xe/0x20 lpfc_unreg_login+0x7c/0xc0 [lpfc] lpfc_sli_def_mbox_cmpl+0x334/0x430 [lpfc] ... When processing the completion of a "Reg Rpi" login mailbox command in lpfc_sli_def_mbox_cmpl, a call may be made to lpfc_unreg_login. The vpi is extracted from the completing mailbox context and passed as an input for the next. However, the vpi stored in the mailbox command context is an absolute vpi, which for SLI4 represents both base + offset. When used with a non-zero base component, (function id > 0) this results in an out-of-range access beyond the allocated phba->vpi_ids array. Fix by subtracting the function's base value to get an accurate vpi number. Link: https://lore.kernel.org/r/20200322181304.37655-2-jsmart2021@gmail.comSigned-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
-
Jeremy Sowden authored
BugLink: https://bugs.launchpad.net/bugs/1878098 commit 01ce31c5 upstream. Removed info log-message if ipip tunnel registration fails during module-initialization: it adds nothing to the error message that is written on all failures. Fixes: dd9ee344 ("vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel") Signed-off-by:
Jeremy Sowden <jeremy@azazel.net> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
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:
-
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:
-
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:
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:
-
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:
-
