- 27 Aug, 2020 18 commits
-
-
Ido Schimmel authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 7d8e8f34 ] The lifetime of the Rx listener item ('rxl_item') is managed using RCU, but is dereferenced outside of RCU read-side critical section, which can lead to a use-after-free. Fix this by increasing the scope of the RCU read-side critical section. Fixes: 93c1edb2 ("mlxsw: Introduce Mellanox switch driver core") Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Ian May <ian.may@canonical.com> Signed-off-by:
Kelsey Skunberg <kelsey.skunberg@canonical.com>
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 63634aa6 ] The interrupt URB transfer-buffer was never freed on disconnect or after probe errors. Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Cc: Woojung.Huh@microchip.com <Woojung.Huh@microchip.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 8d8e95fd ] Add the missing endpoint sanity check to prevent a NULL-pointer dereference should a malicious device lack the expected endpoints. Note that the driver has a broken endpoint-lookup helper, lan78xx_get_endpoints(), which can end up accepting interfaces in an altsetting without endpoints as long as *some* altsetting has a bulk-in and a bulk-out endpoint. Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Cc: Woojung.Huh@microchip.com <Woojung.Huh@microchip.com> Signed-off-by:
-
Michael Karcher authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 04a8a3d0 ] The slow path for traced system call entries accessed a wrong memory location to get the number of the maximum allowed system call number. Renumber the numbered "local" label for the correct location to avoid collisions with actual local labels. Signed-off-by:
Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> Tested-by:
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Fixes: f3a83088 ("sh: Add a few missing irqflags tracing markers.") Signed-off-by:
Rich Felker <dalias@libc.org> Signed-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit 8999dc89 upstream. We should check null before do x25_neigh_put in x25_disconnect, otherwise may cause null-ptr-deref like this: #include <sys/socket.h> #include <linux/x25.h> int main() { int sck_x25; sck_x25 = socket(AF_X25, SOCK_SEQPACKET, 0); close(sck_x25); return 0; } BUG: kernel NULL pointer dereference, address: 00000000000000d8 CPU: 0 PID: 4817 Comm: t2 Not tainted 5.7.0-rc3+ #159 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3- RIP: 0010:x25_disconnect+0x91/0xe0 Call Trace: x25_release+0x18a/0x1b0 __sock_release+0x3d/0xc0 sock_close+0x13/0x20 __fput+0x107/0x270 ____fput+0x9/0x10 task_work_run+0x6d/0xb0 exit_to_usermode_loop+0x102/0x110 do_syscall_64+0x23c/0x260 entry_SYSCALL_64_after_hwframe+0x49/0xb3 Reported-by: syzbot+6db548b615e5aeefdce2@syzkaller.appspotmail.com Fixes: 4becb7ee ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Xiyu Yang authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit 4becb7ee upstream. x25_connect() invokes x25_get_neigh(), which returns a reference of the specified x25_neigh object to "x25->neighbour" with increased refcnt. When x25 connect success and returns, the reference still be hold by "x25->neighbour", so the refcount should be decreased in x25_disconnect() to keep refcount balanced. The reference counting issue happens in x25_disconnect(), which forgets to decrease the refcnt increased by x25_get_neigh() in x25_connect(), causing a refcnt leak. Fix this issue by calling x25_neigh_put() before x25_disconnect() returns. Signed-off-by:
Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by:
Xin Tan <tanxin.ctf@gmail.com> Signed-off-by:
-
Peilin Ye authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit bbc8a99e upstream. rds_notify_queue_get() is potentially copying uninitialized kernel stack memory to userspace since the compiler may leave a 4-byte hole at the end of `cmsg`. In 2016 we tried to fix this issue by doing `= { 0 };` on `cmsg`, which unfortunately does not always initialize that 4-byte hole. Fix it by using memset() instead. Cc: stable@vger.kernel.org Fixes: f037590f ("rds: fix a leak of kernel memory") Fixes: bdbe6fbc ("RDS: recv.c") Suggested-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Peilin Ye <yepeilin.cs@gmail.com> Acked-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
Tetsuo Handa authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 033724d6 ] syzbot is reporting general protection fault in bitfill_aligned() [1] caused by integer underflow in bit_clear_margins(). The cause of this problem is when and how do_vc_resize() updates vc->vc_{cols,rows}. If vc_do_resize() fails (e.g. kzalloc() fails) when var.xres or var.yres is going to shrink, vc->vc_{cols,rows} will not be updated. This allows bit_clear_margins() to see info->var.xres < (vc->vc_cols * cw) or info->var.yres < (vc->vc_rows * ch). Unexpectedly large rw or bh will try to overrun the __iomem region and causes general protection fault. Also, vc_resize(vc, 0, 0) does not set vc->vc_{cols,rows} = 0 due to new_cols = (cols ? cols : vc->vc_cols); new_rows = (lines ? lines : vc->vc_rows); exception. Since cols and lines are calculated as cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres); rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres); cols /= vc->vc_font.width; rows /= vc->vc_font.height; vc_resize(vc, cols, rows); in fbcon_modechanged(), var.xres < vc->vc_font.width makes cols = 0 and var.yres < vc->vc_font.height makes rows = 0. This means that const int fd = open("/dev/fb0", O_ACCMODE); struct fb_var_screeninfo var = { }; ioctl(fd, FBIOGET_VSCREENINFO, &var); var.xres = var.yres = 1; ioctl(fd, FBIOPUT_VSCREENINFO, &var); easily reproduces integer underflow bug explained above. Of course, callers of vc_resize() are not handling vc_do_resize() failure is bad. But we can't avoid vc_resize(vc, 0, 0) which returns 0. Therefore, as a band-aid workaround, this patch checks integer underflow in "struct fbcon_ops"->clear_margins call, assuming that vc->vc_cols * vc->vc_font.width and vc->vc_rows * vc->vc_font.heigh do not cause integer overflow. [1] https://syzkaller.appspot.com/bug?id=a565882df74fa76f10d3a6fec4be31098dbb37c6Reported-and-tested-by:
syzbot <syzbot+e5fd3e65515b48c02a30@syzkaller.appspotmail.com> Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200715015102.3814-1-penguin-kernel@I-love.SAKURA.ne.jpSigned-off-by:
-
Will Deacon authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit eec13b42 ] Unprivileged memory accesses generated by the so-called "translated" instructions (e.g. LDRT) in kernel mode can cause user watchpoints to fire unexpectedly. In such cases, the hw_breakpoint logic will invoke the user overflow handler which will typically raise a SIGTRAP back to the current task. This is futile when returning back to the kernel because (a) the signal won't have been delivered and (b) userspace can't handle the thing anyway. Avoid invoking the user overflow handler for watchpoints triggered by kernel uaccess routines, and instead single-step over the faulting instruction as we would if no overflow handler had been installed. Cc: <stable@vger.kernel.org> Fixes: f81ef4a9 ("ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework") Reported-by:
Luis Machado <luis.machado@linaro.org> Tested-by:
Will Deacon <will@kernel.org> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Sheng Yong authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 720db068 ] Dentry bitmap is not enough to detect incorrect dentries. So this patch also checks the namelen value of a dentry. Signed-off-by:
Gong Chen <gongchen4@huawei.com> Signed-off-by:
Sheng Yong <shengyong1@huawei.com> Reviewed-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Jaegeuk Kim authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 4e240d1b ] If namelen is corrupted to have very long value, fill_dentries can copy wrong memory area. Reviewed-by:
-
Steve Cohen authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit 8490d6a7 upstream. A use-after-free in drm_gem_open_ioctl can happen if the GEM object handle is closed between the idr lookup and retrieving the size from said object since a local reference is not being held at that point. Hold the local reference while the object can still be accessed to fix this and plug the potential security hole. Signed-off-by:
Steve Cohen <cohens@codeaurora.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Peilin Ye authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit 543e8669 upstream. Compiler leaves a 4-byte hole near the end of `dev_info`, causing amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace when `size` is greater than 356. In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which unfortunately does not initialize that 4-byte hole. Fix it by using memset() instead. Cc: stable@vger.kernel.org Fixes: c193fa91 ("drm/amdgpu: information leak in amdgpu_info_ioctl()") Fixes: d38ceaf9 ("drm/amdgpu: add core driver (v4)") Suggested-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Robert Hancock authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit b361663c upstream. Recently ASPM handling was changed to allow ASPM on PCIe-to-PCI/PCI-X bridges. Unfortunately the ASMedia ASM1083/1085 PCIe to PCI bridge device doesn't seem to function properly with ASPM enabled. On an Asus PRIME H270-PRO motherboard, it causes errors like these: pcieport 0000:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID) pcieport 0000:00:1c.0: AER: device [8086:a292] error status/mask=00003000/00002000 pcieport 0000:00:1c.0: AER: [12] Timeout pcieport 0000:00:1c.0: AER: Corrected error received: 0000:00:1c.0 pcieport 0000:00:1c.0: AER: can't find device of ID00e0 In addition to flooding the kernel log, this also causes the machine to wake up immediately after suspend is initiated. The device advertises ASPM L0s and L1 support in the Link Capabilities register, but the ASMedia web page for ASM1083 [1] claims "No PCIe ASPM support". Windows 10 (build 2004) enables L0s, but it also logs correctable PCIe errors. Add a quirk to disable ASPM for this device. [1] https://www.asmedia.com.tw/eng/e_show_products.php?cate_index=169&item=114 [bhelgaas: commit log] Fixes: 66ff14e5 ("PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X Bridges") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208667 Link: https://lore.kernel.org/r/20200722021803.17958-1-hancockrwd@gmail.comSigned-off-by:
Robert Hancock <hancockrwd@gmail.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Andreas Gruenbacher authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit c4803c49 ] Add a nfs_listxattr operation. Move the call to security_inode_listsecurity from list operation of the "security.*" xattr handler to nfs_listxattr. Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Cc: Trond Myklebust <trond.myklebust@primarydata.com> Cc: Anna Schumaker <anna.schumaker@netapp.com> Cc: linux-nfs@vger.kernel.org Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Navid Emamdoost authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 728c1e2a ] In ath9k_wmi_cmd, the allocated network buffer needs to be released if timeout happens. Otherwise memory will be leaked. Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Navid Emamdoost authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 853acf7c ] In htc_config_pipe_credits, htc_setup_complete, and htc_connect_service if time out happens, the allocated buffer needs to be released. Otherwise there will be memory leak. Signed-off-by:
-
Navid Emamdoost authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit a7b2df76 ] In cx23888_ir_probe if kfifo_alloc fails the allocated memory for state should be released. Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
- 11 Aug, 2020 10 commits
-
-
Stefan Bader authored
Signed-off-by:Stefan Bader <stefan.bader@canonical.com>
-
Stefan Bader authored
BugLink: https://bugs.launchpad.net/bugs/1891057 Properties: no-test-build Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by: -
Andy Whitcroft authored
BugLink: https://bugs.launchpad.net/bugs/1861284Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com Signed-off-by:
-
Andy Whitcroft authored
BugLink: https://bugs.launchpad.net/bugs/1861284Signed-off-by:
-
Kleber Sacilotto de Souza authored
BugLink: https://bugs.launchpad.net/bugs/1861284 When the build of wireguard modules is disabled, its modules should be ignored, just like when zfs is disabled. Signed-off-by:
-
Andy Whitcroft authored
BugLink: https://bugs.launchpad.net/bugs/1861284 Add support for building, signing, and shipping the wireguard.ko from the wireguard-dkms package. Drop this into the linux-modules package. Signed-off-by:
-
Andy Whitcroft authored
BugLink: https://bugs.launchpad.net/bugs/1861284 Add new dkms-build scripting which prepares a kernel headers tree and then builds specified DKMS packages against those headers. The resulting .kos are then incorporated into the specified package, including signing them into this kernels module signing key. This allows them to be loaded in a secure-boot environment. Squashes the following commits from bionic: UBUNTU: update dkms package versions UBUNTU: [Config] wireguard -- enable for all architectures UBUNTU: [Packaging]: ignore wireguard modules when wireguard is disabled UBUNTU: [Packaging] wireguard -- add support for building signed .ko dkms-build: apt-cache policy elides username:password information UBUNTU: [Packaging] file-downloader not handling positive failures correctly UBUNTU: temporarily drop Built-Using data UBUNTU: [packaging] handle downloads from the librarian better UBUNTU: [Packaging] autoreconstruct -- manage executable debian files UBUNTU: [Packaging] Fix config file assembly UBUNTU: [Packaging] dkms -- dkms-build quieten wget verbiage UBUNTU: [Packaging] dkms -- try launchpad librarian for pool downloads UBUNTU: [Packaging] dkms-build -- backport latest version from disco UBUNTU: [Packaging] dkms-build -- add support for unversioned overrides UBUNTU: [Packaging] dkms-build: do not redownload files on subsequent passes UBUNTU: [Packaging] dkms-build -- support building against packages in PPAs UBUNTU: [Packaging] dkms -- switch to a consistent build prefix length and strip UBUNTU: [Packaging] dkms -- add per package post-process step UBUNTU: [Packaging] dkms -- dkms package build packaging support Signed-off-by:
-
Andy Whitcroft authored
BugLink: https://bugs.launchpad.net/bugs/1861284 We generally mitigate executables within the debian directory but it would be much simpler if we extended executable bit management into debian too. Drop the exclusion there. Signed-off-by:
-
Xin Long authored
BugLink: https://bugs.launchpad.net/bugs/1890796 In commit ed17b8d3 ("xfrm: fix a warning in xfrm_policy_insert_list"), it would take 'priority' to make a policy unique, and allow duplicated policies with different 'priority' to be added, which is not expected by userland, as Tobias reported in strongswan. To fix this duplicated policies issue, and also fix the issue in commit ed17b8d3 ("xfrm: fix a warning in xfrm_policy_insert_list"), when doing add/del/get/update on user interfaces, this patch is to change to look up a policy with both mark and mask by doing: mark.v == pol->mark.v && mark.m == pol->mark.m and leave the check: (mark & pol->mark.m) == pol->mark.v for tx/rx path only. As the userland expects an exact mark and mask match to manage policies. v1->v2: - make xfrm_policy_mark_match inline and fix the changelog as Tobias suggested. Fixes: 295fae56 ("xfrm: Allow user space manipulation of SPD mark") Fixes: ed17b8d3 ("xfrm: fix a warning in xfrm_policy_insert_list") Reported-by:
Tobias Brunner <tobias@strongswan.org> Tested-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> (backported from commit 4f47e8ab) [smb: work around missing if_id parameter and __xfrm_policy_bysel_ctx] Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by:
-
- 09 Aug, 2020 12 commits
-
-
Khalid Elmously authored
Signed-off-by: -
Khalid Elmously authored
BugLink: https://bugs.launchpad.net/bugs/1890670 Properties: no-test-build Signed-off-by:
-
Kamal Mostafa authored
BugLink: https://bugs.launchpad.net/bugs/1889928 Ignore: yes Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1889928Signed-off-by:
-
Masami Hiramatsu authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 80526491 upstream. Fix to check kprobe blacklist address correctly with relocated address by adjusting debuginfo address. Since the address in the debuginfo is same as objdump, it is different from relocated kernel address with KASLR. Thus, 'perf probe' always misses to catch the blacklisted addresses. Without this patch, 'perf probe' can not detect the blacklist addresses on a KASLR enabled kernel. # perf probe kprobe_dispatcher Failed to write event: Invalid argument Error: Failed to add events. # With this patch, it correctly shows the error message. # perf probe kprobe_dispatcher kprobe_dispatcher is blacklisted function, skip it. Probe point 'kprobe_dispatcher' not found. Error: Failed to add events. # Fixes: 9aaf5a5f ("perf probe: Check kprobes blacklist when adding new events") Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Tested-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/158763966411.30755.5882376357738273695.stgit@devnote2Signed-off-by:
-
Arnaldo Carvalho de Melo authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 6810158d upstream. We were using a local buffer with an arbitrary size, that would have to get increased to avoid truncation as warned by gcc 8: util/annotate.c: In function 'symbol__disassemble': util/annotate.c:1488:4: error: '%s' directive output may be truncated writing up to 4095 bytes into a region of size between 3966 and 8086 [-Werror=format-truncation=] "%s %s%s --start-address=0x%016" PRIx64 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ util/annotate.c:1498:20: symfs_filename, symfs_filename); ~~~~~~~~~~~~~~ util/annotate.c:1490:50: note: format string is defined here " -l -d %s %s -C \"%s\" 2>/dev/null|grep -v \"%s:\"|expand", ^~ In file included from /usr/include/stdio.h:861, from util/color.h:5, from util/sort.h:8, from util/annotate.c:14: /usr/include/bits/stdio2.h:67:10: note: '__builtin___snprintf_chk' output 116 or more bytes (assuming 8331) into a destination of size 8192 return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ __bos (__s), __fmt, __va_arg_pack ()); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ So switch to asprintf, that will make sure enough space is available. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: https://lkml.kernel.org/n/tip-qagoy2dmbjpc9gdnaj0r3mml@git.kernel.orgSigned-off-by:
-
Jiri Olsa authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 77f18153 upstream. [Add an additional sprintf replacement in tools/perf/builtin-script.c] With gcc 8 we get new set of snprintf() warnings that breaks the compilation, one example: tests/mem.c: In function ‘check’: tests/mem.c:19:48: error: ‘%s’ directive output may be truncated writing \ up to 99 bytes into a region of size 89 [-Werror=format-truncation=] snprintf(failure, sizeof failure, "unexpected %s", out); The gcc docs says: To avoid the warning either use a bigger buffer or handle the function's return value which indicates whether or not its output has been truncated. Given that all these warnings are harmless, because the code either properly fails due to uncomplete file path or we don't care for truncated output at all, I'm changing all those snprintf() calls to scnprintf(), which actually 'checks' for the snprint return value so the gcc stays silent. Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Link: http://lkml.kernel.org/r/20180319082902.4518-1-jolsa@kernel.orgSigned-off-by:
-
Changbin Du authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 0ada120c upstream. libbfd has changed the bfd_section_* macros to inline functions bfd_section_<field> since 2019-09-18. See below two commits: o http://www.sourceware.org/ml/gdb-cvs/2019-09/msg00064.html o https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00072.html This fix make perf able to build with both old and new libbfd. Signed-off-by:
Changbin Du <changbin.du@gmail.com> Acked-by:
Jiri Olsa <jolsa@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20200128152938.31413-1-changbin.du@gmail.comSigned-off-by:
-
Sergey Senozhatsky authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit dfbc3c6c upstream. [ Change applied file from tools/lib/subcmd/pager.c to tools/perf/util/pager.c ] Use a separate fd set for select()-s exception fds param to fix the following gcc warning: pager.c:36:12: error: passing argument 2 to restrict-qualified parameter aliases with argument 4 [-Werror=restrict] select(1, &in, NULL, &in, NULL); ^~~ ~~~ Link: http://lkml.kernel.org/r/20180101105626.7168-1-sergey.senozhatsky@gmail.comSigned-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Eric Sandeen authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 2c4306f7 upstream. If xfs_bmap_extents_to_btree fails in a mode where we call xfs_iroot_realloc(-1) to de-allocate the root, set the format back to extents. Otherwise we can assume we can dereference ifp->if_broot based on the XFS_DINODE_FMT_BTREE format, and crash. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199423Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by:
-
Peng Fan authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit 74edd08a upstream. When executing the following command, we met kernel dump. dmesg -c > /dev/null; cd /sys; for i in `ls /sys/kernel/debug/regmap/* -d`; do echo "Checking regmap in $i"; cat $i/registers; done && grep -ri "0x02d0" *; It is because the count value is too big, and kmalloc fails. So add an upper bound check to allow max size `PAGE_SIZE << (MAX_ORDER - 1)`. Signed-off-by:
Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1584064687-12964-1-git-send-email-peng.fan@nxp.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Fangrui Song authored
BugLink: https://bugs.launchpad.net/bugs/1889928 commit ca9b31f6 upstream. When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit, GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to /usr/bin/ and Clang as of 11 will search for both $(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle. GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle, $(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice, $(prefix)aarch64-linux-gnu/$needle rarely contains executables. To better model how GCC's -B/--prefix takes in effect in practice, newer Clang (since https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90) only searches for $(prefix)$needle. Currently it will find /usr/bin/as instead of /usr/bin/aarch64-linux-gnu-as. Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) (/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the appropriate cross compiling GNU as (when -no-integrated-as is in effect). Cc: stable@vger.kernel.org Reported-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Fangrui Song <maskray@google.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1099Reviewed-by:
Masahiro Yamada <masahiroy@kernel.org> [nc: Adjust context, CLANG_FLAGS does not exist in 4.4] Signed-off-by:
-
