- 03 Dec, 2019 40 commits
-
-
Jia-Ju Bai authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 2337a77c ] The driver may sleep in an interrupt handler. The function call path (from bottom to top) in Linux-4.17 is: [FUNC] fotg210_ep_queue(GFP_KERNEL) drivers/usb/gadget/udc/fotg210-udc.c, 744: fotg210_ep_queue in fotg210_get_status drivers/usb/gadget/udc/fotg210-udc.c, 768: fotg210_get_status in fotg210_setup_packet drivers/usb/gadget/udc/fotg210-udc.c, 949: fotg210_setup_packet in fotg210_irq (interrupt handler) To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC. If possible, spin_unlock() and spin_lock() around fotg210_ep_queue() can be also removed. This bug is found by my static analysis tool DSAC. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Simon Wunderlich authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 4fb5837a ] Since the debug print code is outside of the loop, it shouldn't use the loop iterator anymore but instead print the found maximum index. Cc: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Ben Greear authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 833fd34d ] The vdev-start-response message should cause the completion to fire, even in the error case. Otherwise, the user still gets no useful information and everything is blocked until the timeout period. Add some warning text to print out the invalid status code to aid debugging, and propagate failure code. Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
Trond Myklebust authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit f42f7c28 ] Fix up the priority queue to not batch by owner, but by queue, so that we allow '1 << priority' elements to be dequeued before switching to the next priority queue. The owner field is still used to wake up requests in round robin order by owner to avoid single processes hogging the RPC layer by loading the queues. Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Jaegeuk Kim authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 61f7725a ] This fixes overriding error number in f2fs_gc. Reviewed-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit eddf11e1 ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Jens Axboe authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 2d727150 upstream. For passthrough requests, libata-scsi takes what the user passes in as gospel. This can be problematic if the user fills in the CDB incorrectly. One example of that is in request sizes. For read/write commands, the CDB contains fields describing the transfer length of the request. These should match with the SG_IO header fields, but libata-scsi currently does no validation of that. Check that the number of blocks in the CDB for passthrough requests matches what was mapped into the request. If the CDB asks for more data then the validated SG_IO header fields, error it. Reported-by:
Krishna Ram Prakash R <krp@gtux.in> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Christoph Hellwig authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 57292b58 upstream. This can be used to check for fs vs non-fs requests and basically removes all knowledge of BLOCK_PC specific from the block layer, as well as preparing for removing the cmd_type field in struct request. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@fb.com> [only take the blkdev.h changes as we only want the function for backported patches - gregkh] Signed-off-by:
-
Daniel Vetter authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 3b8720e6 upstream. It's dead code ever since commit 34280340 Author: Geert Uytterhoeven <geert+renesas@glider.be> Date: Fri Dec 4 17:01:43 2015 +0100 fbdev: Remove unused SH-Mobile HDMI driver Also with this gone we can remove the cea_modes db. This entire thing is massively incomplete anyway, compared to the CEA parsing that drm_edid.c does. Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Tavis Ormandy <taviso@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190721201956.941-1-daniel.vetter@ffwll.chSigned-off-by:
-
Geert Uytterhoeven authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 34280340 upstream. As of commit 44d88c75 ("ARM: shmobile: Remove legacy SoC code for R-Mobile A1"), the SH-Mobile HDMI driver is no longer used. In theory it could still be used on R-Mobile A1 SoCs, but that requires adding DT support to the driver, which is not planned. Remove the driver, it can be resurrected from git history when needed. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1853881 Ubuntu commit 430470d7fa02 ("fbdev: Remove unused SH-Mobile HDMI driver") from an upstream stable update removes this driver. Signed-off-by:
-
Masami Hiramatsu authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 13ebe18c upstream. Since MOV SS and POP SS instructions will delay the exceptions until the next instruction is executed, single-stepping on it by uprobes must be prohibited. uprobe already rejects probing on POP SS (0x1f), but allows probing on MOV SS (0x8e and reg == 2). This checks the target instruction and if it is MOV SS or POP SS, returns -ENOTSUPP to reject probing. Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Oleg Nesterov <oleg@redhat.com> Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Cc: Francis Deslauriers <francis.deslauriers@efficios.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H . Peter Anvin" <hpa@zytor.com> Cc: Yonghong Song <yhs@fb.com> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: "David S . Miller" <davem@davemloft.net> Link: https://lkml.kernel.org/r/152587072544.17316.5950935243917346341.stgit@devboxSigned-off-by:
-
Masami Hiramatsu authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit ee6a7354 upstream. Since MOV SS and POP SS instructions will delay the exceptions until the next instruction is executed, single-stepping on it by kprobes must be prohibited. However, kprobes usually executes those instructions directly on trampoline buffer (a.k.a. kprobe-booster), except for the kprobes which has post_handler. Thus if kprobe user probes MOV SS with post_handler, it will do single-stepping on the MOV SS. This means it is safe that if it is used via ftrace or perf/bpf since those don't use the post_handler. Anyway, since the stack switching is a rare case, it is safer just rejecting kprobes on such instructions. Signed-off-by:
-
Peter Zijlstra authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 69d927bb upstream. Recent probing at the Linux Kernel Memory Model uncovered a 'surprise'. Strongly ordered architectures where the atomic RmW primitive implies full memory ordering and smp_mb__{before,after}_atomic() are a simple barrier() (such as x86) fail for: *x = 1; atomic_inc(u); smp_mb__after_atomic(); r0 = *y; Because, while the atomic_inc() implies memory order, it (surprisingly) does not provide a compiler barrier. This then allows the compiler to re-order like so: atomic_inc(u); *x = 1; smp_mb__after_atomic(); r0 = *y; Which the CPU is then allowed to re-order (under TSO rules) like: atomic_inc(u); r0 = *y; *x = 1; And this very much was not intended. Therefore strengthen the atomic RmW ops to include a compiler barrier. NOTE: atomic_{or,and,xor} and the bitops already had the compiler barrier. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Jari Ruusu <jari.ruusu@gmail.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit a56dcc6b upstream. This code is supposed to test for negative error codes and partial reads, but because sizeof() is size_t (unsigned) type then negative error codes are type promoted to high positive values and the condition doesn't work as expected. Fixes: 332f989a ("CDC-NCM: handle incomplete transfer of MTU") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by:
-
Jouni Hogander authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit ed50e160 upstream. This patch is fixing memory leak reported by Syzkaller: BUG: memory leak unreferenced object 0xffff888067f65500 (size 4096): comm "syz-executor043", pid 454, jiffies 4294759719 (age 11.930s) hex dump (first 32 bytes): 73 6c 63 61 6e 30 00 00 00 00 00 00 00 00 00 00 slcan0.......... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000a06eec0d>] __kmalloc+0x18b/0x2c0 [<0000000083306e66>] kvmalloc_node+0x3a/0xc0 [<000000006ac27f87>] alloc_netdev_mqs+0x17a/0x1080 [<0000000061a996c9>] slcan_open+0x3ae/0x9a0 [<000000001226f0f9>] tty_ldisc_open.isra.1+0x76/0xc0 [<0000000019289631>] tty_set_ldisc+0x28c/0x5f0 [<000000004de5a617>] tty_ioctl+0x48d/0x1590 [<00000000daef496f>] do_vfs_ioctl+0x1c7/0x1510 [<0000000059068dbc>] ksys_ioctl+0x99/0xb0 [<000000009a6eb334>] __x64_sys_ioctl+0x78/0xb0 [<0000000053d0332e>] do_syscall_64+0x16f/0x580 [<0000000021b83b99>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<000000008ea75434>] 0xffffffffffffffff Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
Jouni Hogander <jouni.hogander@unikie.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Cc: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
-
zhong jiang authored
BugLink: https://bugs.launchpad.net/bugs/1853881 The commit eb4058d8daf8 ("memfd: Fix locking when tagging pins") introduces the following warning messages. *WARNING: suspicious RCU usage in memfd_wait_for_pins* It is because we still use radix_tree_deref_slot without read_rcu_lock. We should use radix_tree_deref_slot_protected instead in the case. Cc: stable@vger.kernel.org Fixes: eb4058d8daf8 ("memfd: Fix locking when tagging pins") Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Reviewed-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by:
-
Kefeng Wang authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 56897b21 upstream. task A: task B: hci_uart_set_proto flush_to_ldisc - p->open(hu) -> h5_open //alloc h5 - receive_buf - set_bit HCI_UART_PROTO_READY - tty_port_default_receive_buf - hci_uart_register_dev - tty_ldisc_receive_buf - hci_uart_tty_receive - test_bit HCI_UART_PROTO_READY - h5_recv - clear_bit HCI_UART_PROTO_READY while() { - p->open(hu) -> h5_close //free h5 - h5_rx_3wire_hdr - h5_reset() //use-after-free } It could use ioctl to set hci uart proto, but there is a use-after-free issue when hci_uart_register_dev() fail in hci_uart_set_proto(), see stack above, fix this by setting HCI_UART_PROTO_READY bit only when hci_uart_register_dev() return success. Reported-by: syzbot+899a33dc0fa0dbaf06a6@syzkaller.appspotmail.com Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by:
Jeremy Cline <jcline@redhat.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Cc: Ralph Siemsen <ralph.siemsen@linaro.org> Signed-off-by:
-
Loic Poulain authored
BugLink: https://bugs.launchpad.net/bugs/1853881 commit 84cb3df0 upstream. HCI_UART_PROTO_SET flag is set before hci_uart_set_proto call. If we receive data from tty layer during this procedure, proto pointer may not be assigned yet, leading to null pointer dereference in rx method hci_uart_tty_receive. This patch fixes this issue by introducing HCI_UART_PROTO_READY flag in order to avoid any proto operation before proto opening and assignment. Signed-off-by:
Loic Poulain <loic.poulain@intel.com> Signed-off-by:
-
Kirill Tkhai authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 2a23f2b8 ] Since they are of unsigned int type, it's allowed to read them unlocked during reporting to userspace. Let's underline this fact with READ_ONCE() macroses. Signed-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Rob Herring authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit e9f0878c ] dtc has new checks for SPI buses. Fix the warnings in node names. arch/arm64/boot/dts/amd/amd-overdrive.dtb: Warning (spi_bus_bridge): /smb/ssp@e1030000: node name for SPI buses should be 'spi' arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dtb: Warning (spi_bus_bridge): /smb/ssp@e1030000: node name for SPI buses should be 'spi' arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dtb: Warning (spi_bus_bridge): /smb/ssp@e1030000: node name for SPI buses should be 'spi' Cc: Brijesh Singh <brijeshkumar.singh@amd.com> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Luiz Augusto von Dentz authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit a5c3021b ] If the remote is not able to fully utilize the MPS choosen recalculate the credits based on the actual amount it is sending that way it can still send packets of MTU size without credits dropping to 0. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
-
Justin Ernst authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 6b588594 ] We observe an oops in the skx_edac module during boot: EDAC MC0: Giving out device to module skx_edac controller Skylake Socket#0 IMC#0 EDAC MC1: Giving out device to module skx_edac controller Skylake Socket#0 IMC#1 EDAC MC2: Giving out device to module skx_edac controller Skylake Socket#1 IMC#0 ... EDAC MC13: Giving out device to module skx_edac controller Skylake Socket#0 IMC#1 EDAC MC14: Giving out device to module skx_edac controller Skylake Socket#1 IMC#0 EDAC MC15: Giving out device to module skx_edac controller Skylake Socket#1 IMC#1 Too many memory controllers: 16 EDAC MC: Removed device 0 for skx_edac Skylake Socket#0 IMC#0 We observe there are two memory controllers per socket, with a limit of 16. Raise the maximum number of memory controllers from 16 to 2 * MAX_NUMNODES (1024). [ bp: This is just a band-aid fix until we've sorted out the whole issue with the bus_type association and handling in EDAC and can get rid of this arbitrary limit. ] Signed-off-by:
Justin Ernst <justin.ernst@hpe.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Russ Anderson <russ.anderson@hpe.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: linux-edac@vger.kernel.org Link: https://lkml.kernel.org/r/20180925143449.284634-1-justin.ernst@hpe.comSigned-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 6323d57f ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
Marcel Ziswiler authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 1c997fe4 ] Fix MMC1 cmd pin pull-up causing issues on carrier boards without external pull-up. Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Marcel Ziswiler authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 564706f6 ] There was a dot instead of a comma. Fix this. Signed-off-by:
-
Jason Yan authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 32c850bf ] If we went into sas_rediscover_dev() the attached_sas_addr was already insured not to be zero. So it's unnecessary to check if the attached_sas_addr is zero. And although if the sas address is not changed, we always have to unregister the old device when we are going to register a new one. We cannot just leave the device there and bring up the new. Signed-off-by:
Jason Yan <yanaijie@huawei.com> CC: chenxiang <chenxiang66@hisilicon.com> CC: John Garry <john.garry@huawei.com> CC: Johannes Thumshirn <jthumshirn@suse.de> CC: Ewan Milne <emilne@redhat.com> CC: Christoph Hellwig <hch@lst.de> CC: Tomas Henzl <thenzl@redhat.com> CC: Dan Williams <dan.j.williams@intel.com> CC: Hannes Reinecke <hare@suse.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Li Qiang authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 30ea32ab ] Free allocated vdev->msi_perm in error path. Signed-off-by:
Li Qiang <liq3ea@gmail.com> Reviewed-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
zhong jiang authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 02241995 ] The function should return -EFAULT when copy_from_user fails. Even though the caller does not distinguish them. but we should keep backward compatibility. Signed-off-by:
-
Laura Abbott authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit fa0218ef ] kgdbts current fails when compiled with restrict: drivers/misc/kgdbts.c: In function ‘configure_kgdbts’: drivers/misc/kgdbts.c:1070:2: error: ‘strcpy’ source argument is the same as destination [-Werror=restrict] strcpy(config, opt); ^~~~~~~~~~~~~~~~~~~ As the error says, config is being used in both the source and destination. Refactor the code to avoid the extra copy and put the parsing closer to the actual location. Signed-off-by:
Laura Abbott <labbott@redhat.com> Acked-by:
Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by:
-
Laurent Pinchart authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 8dbf9c7a ] When USB requests for video data fail to be submitted, the driver signals a problem to the host by halting the video streaming endpoint. This is only valid in bulk mode, as isochronous transfers have no handshake phase and can't thus report a stall. The usb_ep_set_halt() call returns an error when using isochronous endpoints, which we happily ignore, but some UDCs complain in the kernel log. Fix this by only trying to halt the endpoint in bulk mode. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Paul Elder <paul.elder@ideasonboard.com> Tested-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 9d1ff5dc ] USB requests for video data are queued from two different locations in the driver, with the same code block occurring twice. Factor it out to a function. Signed-off-by:
-
Joel Pepper authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit cb2200f7 ] While checks are in place to avoid attributes and children of a format being manipulated after the format is linked into the streaming header, the linked flag was never actually set, invalidating the protections. Update the flag as appropriate in the header link calls. Signed-off-by:
Joel Pepper <joel.pepper@rwth-aachen.de> Reviewed-by:
-
Laurent Pinchart authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 86f3daed ] Some of the .allow_link() and .drop_link() operations implementations call config_group_find_item() and then leak the reference to the returned item. Fix this by dropping those references where needed. Signed-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 41587573 ] Clang warns when one enumerated type is implicitly converted to another. drivers/media/platform/davinci/vpbe_display.c:524:24: warning: implicit conversion from enumeration type 'enum osd_v_exp_ratio' to different enumeration type 'enum osd_h_exp_ratio' [-Wenum-conversion] layer_info->h_exp = V_EXP_6_OVER_5; ~ ^~~~~~~~~~~~~~ 1 warning generated. This appears to be a copy and paste error judging from the couple of lines directly above this statement and the way that height is handled in the if block above this one. Reported-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Jia-Ju Bai authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 8d11eb84 ] The driver may sleep in a interrupt handler. The function call paths (from bottom to top) in Linux-4.16 are: [FUNC] kzalloc(GFP_KERNEL) drivers/media/pci/ivtv/ivtv-yuv.c, 938: kzalloc in ivtv_yuv_init drivers/media/pci/ivtv/ivtv-yuv.c, 960: ivtv_yuv_init in ivtv_yuv_next_free drivers/media/pci/ivtv/ivtv-yuv.c, 1126: ivtv_yuv_next_free in ivtv_yuv_setup_stream_frame drivers/media/pci/ivtv/ivtv-irq.c, 827: ivtv_yuv_setup_stream_frame in ivtv_irq_dec_data_req drivers/media/pci/ivtv/ivtv-irq.c, 1013: ivtv_irq_dec_data_req in ivtv_irq_handler To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool DSAC. Signed-off-by:
-
Dengcheng Zhu authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit a6da4d6f ] We can rely on the system kernel and the dump capture kernel themselves in memory usage. Being restrictive with 512MB limit may cause kexec tool failure on some platforms. Tested-by:
Rachel Mozes <rachel.mozes@intel.com> Reported-by:
Dengcheng Zhu <dzhu@wavecomp.com> Signed-off-by:
Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/20568/ Cc: pburton@wavecomp.com Cc: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Signed-off-by:
-
Matthew Whitehead authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 03b099bd ] There are comments in processor-cyrix.h advising you to _not_ make calls using the deprecated macros in this style: setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80); This is because it expands the macro into a non-functioning calling sequence. The calling order must be: outb(CX86_CCR2, 0x22); inb(0x23); From the comments: * When using the old macros a line like * setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88); * gets expanded to: * do { * outb((CX86_CCR2), 0x22); * outb((({ * outb((CX86_CCR2), 0x22); * inb(0x23); * }) | 0x88), 0x23); * } while (0); The new macros fix this problem, so use them instead. Signed-off-by:
Matthew Whitehead <tedheadster@gmail.com> Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jia Zhang <qianyue.zj@alibaba-inc.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20180921212041.13096-2-tedheadster@gmail.comSigned-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 2b49117a ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
Shahed Shaikh authored
BugLink: https://bugs.launchpad.net/bugs/1853881 [ Upstream commit 75a110a1 ] This is a workaround for FW bug - MFW generates bandwidth attention in single function mode, which is only expected to be generated in multi function mode. This undesired attention in SF mode results in incorrect HW configuration and resulting into Tx timeout. Signed-off-by:
Shahed Shaikh <Shahed.Shaikh@cavium.com> Signed-off-by:
Ariel Elior <ariel.elior@cavium.com> Signed-off-by:
-
