summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-05-28perf data: Fix 'strncat may truncate' build failure with recent gccShawn Landden
This strncat() is safe because the buffer was allocated with zalloc(), however gcc doesn't know that. Since the string always has 4 non-null bytes, just use memcpy() here. CC /home/shawn/linux/tools/perf/util/data-convert-bt.o In file included from /usr/include/string.h:494, from /home/shawn/linux/tools/lib/traceevent/event-parse.h:27, from util/data-convert-bt.c:22: In function ‘strncat’, inlined from ‘string_set_value’ at util/data-convert-bt.c:274:4: /usr/include/powerpc64le-linux-gnu/bits/string_fortified.h:136:10: error: ‘__builtin_strncat’ output may be truncated copying 4 bytes from a string of length 4 [-Werror=stringop-truncation] 136 | return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Shawn Landden <shawn@git.icu> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> LPU-Reference: 20190518183238.10954-1-shawn@git.icu Link: https://lkml.kernel.org/n/tip-289f1jice17ta7tr3tstm9jm@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-05-28arm64: Fix the arm64_personality() syscall wrapper redirectionCatalin Marinas
Following commit 4378a7d4be30 ("arm64: implement syscall wrappers"), the syscall function names gained the '__arm64_' prefix. Ensure that we have the correct #define for redirecting a default syscall through a wrapper. Fixes: 4378a7d4be30 ("arm64: implement syscall wrappers") Cc: <stable@vger.kernel.org> # 4.19.x- Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-05-28bus: ti-sysc: Detect uarts also on omap34xxTony Lindgren
Looks like we currently only detect UART on omap36xx, let's also add support for omap34xx. And let's also fix the SWSUP mode, it should be SWSUP_SIDLE for omap3, not SWSUP_SIDLE_ACT like for omap4 and later. Note that we are still booting omap3 for most part without ti-sysc, so no need to treat this change as a fix. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-28bus: ti-sysc: Do rstctrl reset handling in two phasesTony Lindgren
We need to deassert rstctrl resets before enabling clocks to avoid clock "failed to enable" errors. For asserting rstctrl reset, the clocks need to be enabled. As the reset controller status is not available for arrays, let's use devm_reset_control_get_optional() so we can get the status after reset. Note that depends on a proper PRM rstctrl driver, so far I've only tested this with earlier reset-simple patches. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-28bus: ti-sysc: Add support for disabling module without legacy modeTony Lindgren
We must not assert reset for modules with no child device drivers until in runtime_suspend. Otherwise register access will fail without legacy mode helping us. Let's add a flag for disable_on_idle and move the reset driver handling to runtime suspend and resume. We can then also use the disable_on_idle flag to reconfigure sysconfig register for PM modes requesting it. Let's also make the other flags use bitfield while at it instead of bool. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-28bus: ti-sysc: Set ENAWAKEUP if availableTony Lindgren
Some modules have ENAWAKEUP bit that we need to configure when not relying on platform data callbacks. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-28bus: ti-sysc: Handle swsup idle mode quirksTony Lindgren
Some modules have idlemodes wired, but not completely functional. We have quirks for SWSUP_SIDLE and SWSUP_SIDLE_ACT to manage interconnect target modules without hardware support, but we've been only using them so far in legacy mode. Let's add support for SWSUP quirks in non-legacy mode too. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-28bus: ti-sysc: Handle clockactivity for enable and disableTony Lindgren
Modules with clockactivity need it configured during enable. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-28bus: ti-sysc: Enable interconnect target module autoidle bit on enableTony Lindgren
For interconnect target modules with autoidle bit wired, we need to manage it for enable and disable. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-28bus: ti-sysc: Allow QUIRK_LEGACY_IDLE even if legacy_mode is not setTony Lindgren
We need to specify QUIRK_LEGACY_IDLE for device drivers that still have pm_runtime_irq_safe() set like 8250. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-28bus: ti-sysc: Make OCP reset work for sysstatus and sysconfig reset bitsTony Lindgren
We've had minimal OCP softreset support in ti-sysc interconnect target module driver only used for MCAN driver so far. But it turns out that MCAN has the sysstatus register resetdone bit inverted compared to most other modules. Let's make OCP softreset work for other typical cases with reset status in sysstatus or sysconfig register so we can use the new functions for sysc_enable_module() and sysc_disable_module() without "ti,hwmods" property in the following patches. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-28bus: ti-sysc: Support 16-bit writes tooTony Lindgren
We need to also support 16-bit writes for i2c in addition to the reads when we start configuring the sysconfig register for reset and idle modes. Note that only i2c revision register has LO and HI registers, so let's add a check also for 16-bit register read. This change is currently cosmetic and does not affect anything until we enable the module specific quirk handling for i2c reset and enable later on. Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-28bus: ti-sysc: Add support for missing clockdomain handlingTony Lindgren
We need to let ti-sysc driver manage clockdomain autoidle for the duration of of reset, enable and idle. And we need to do it before we enable the clock and after we disable it. Currently we are still relying on platform callbacks indirectly managing clockdomain autoidle. But I noticed that for device tree only probed drivers it now happens only after we enabling the clocks and before we disable the clocks, while it should be the other way around. So far I have not noticed any issues with this though. Let's add new ti_sysc_clkdm_deny_idle() and ti_sysc_clkdm_allow_idle() functions for ti-sysc driver to use to manage clockdomains directly via platform data callbacks. Note that we can implement the clockdomain functions in pdata-quirks.c as for probing devices without "ti,hwmods" custom property we don't need to use the other platform data callbacks. Let's do this in one patch as there's is still an unlikely chance we may need to apply this as a fix for v5.2 for dropping legacy platform data for some devices. We also do have the option of adding back the platform data if needed in case of trouble. Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-05-28fuse: extract helper for range writebackMiklos Szeredi
The fuse_writeback_range() helper flushes dirty data to the userspace filesystem. When the function returns, the WRITE requests for the data in the given range have all been completed. This is not equivalent to fsync() on the given range, since the userspace filesystem may not yet have the data on stable storage. Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2019-05-28fuse: fix copy_file_range() in the writeback caseMiklos Szeredi
Prior to sending COPY_FILE_RANGE to userspace filesystem, we must flush all dirty pages in both the source and destination files. This patch adds the missing flush of the source file. Tested on libfuse-3.5.0 with: libfuse/example/passthrough_ll /mnt/fuse/ -o writeback libfuse/test/test_syscalls /mnt/fuse/tmp/test Fixes: 88bc7d5097a1 ("fuse: add support for copy_file_range()") Cc: <stable@vger.kernel.org> # v4.20 Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2019-05-28mmc: meson-gx: fix irq ackJerome Brunet
While cleaning the ISR of the meson-gx and acking only raised irqs, the ack of the irq was moved at the very last stage of the function. This was stable during the initial tests but it triggered issues with hs200, under specific loads (like booting android). Acking the irqs after calling the mmc_request_done() causes the problem. Moving the ack back to the original place solves the issue. Since the irq is edge triggered, it does not hurt to ack irq even earlier, so let's do it early in the ISR. Fixes: 9c5fdb07a28d ("mmc: meson-gx: ack only raised irq") Tested-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Brad Harper <bjharper@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-05-28mmc: tmio: fix SCC error handling to avoid false positive CRC errorTakeshi Saito
If an SCC error occurs during a read/write command execution, a false positive CRC error message is output. mmcblk0: response CRC error sending r/w cmd command, card status 0x900 check_scc_error() checks SCC_RVSREQ.RVSERR bit. RVSERR detects a correction error in the next (up or down) delay tap position. However, since the command is successful, only retuning needs to be executed. This has been confirmed by HW engineers. Thus, on SCC error, set retuning flag instead of setting an error code. Fixes: b85fb0a1c8ae ("mmc: tmio: Fix SCC error detection") Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com> [wsa: updated comment and commit message, removed some braces] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-05-28mmc: tegra: Fix a warning messageDan Carpenter
The WARN_ON() macro takes a condition, not a warning message. I've changed this to use WARN(1, "msg... Fixes: ea8fc5953e8b ("mmc: tegra: update hw tuning process") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-05-28memstick: mspro_block: Fix an error code in mspro_block_issue_req()Dan Carpenter
We accidentally changed the error code from -EAGAIN to 1 when we did the blk-mq conversion. Maybe a contributing factor to this mistake is that it wasn't obvious that the "while (chunk) {" condition is always true. I have cleaned that up as well. Fixes: d0be12274dad ("mspro_block: convert to blk-mq") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-05-28ALSA: line6: Assure canceling delayed work at disconnectionTakashi Iwai
The current code performs the cancel of a delayed work at the late stage of disconnection procedure, which may lead to the access to the already cleared state. This patch assures to call cancel_delayed_work_sync() at the beginning of the disconnection procedure for avoiding that race. The delayed work object is now assigned in the common line6 object instead of its derivative, so that we can call cancel_delayed_work_sync(). Along with the change, the startup function is called via the new callback instead. This will make it easier to port other LINE6 drivers to use the delayed work for startup in later patches. Reported-by: syzbot+5255458d5e0a2b10bbb9@syzkaller.appspotmail.com Fixes: 7f84ff68be05 ("ALSA: line6: toneport: Fix broken usage of timer for delayed execution") Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-05-28configfs: Fix use-after-free when accessing sd->s_dentrySahitya Tummala
In the vfs_statx() context, during path lookup, the dentry gets added to sd->s_dentry via configfs_attach_attr(). In the end, vfs_statx() kills the dentry by calling path_put(), which invokes configfs_d_iput(). Ideally, this dentry must be removed from sd->s_dentry but it doesn't if the sd->s_count >= 3. As a result, sd->s_dentry is holding reference to a stale dentry pointer whose memory is already freed up. This results in use-after-free issue, when this stale sd->s_dentry is accessed later in configfs_readdir() path. This issue can be easily reproduced, by running the LTP test case - sh fs_racer_file_list.sh /config (https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/racer/fs_racer_file_list.sh) Fixes: 76ae281f6307 ('configfs: fix race between dentry put and lookup') Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-05-28ALSA: hda - Force polling mode on CNL for fixing codec communicationBard Liao
We observed the same issue as reported by commit a8d7bde23e7130686b7662 ("ALSA: hda - Force polling mode on CFL for fixing codec communication") We don't have a better solution. So apply the same workaround to CNL. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-05-27i2c: synquacer: fix synquacer_i2c_doxfer() return valueMasahisa Kojima
master_xfer should return the number of messages successfully processed. Fixes: 0d676a6c4390 ("i2c: add support for Socionext SynQuacer I2C controller") Cc: <stable@vger.kernel.org> # v4.19+ Signed-off-by: Okamoto Satoru <okamoto.satoru@socionext.com> Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-05-27i2c: mlxcpld: Fix wrong initialization order in probeVadim Pasternak
Fix wrong order in probing routine initialization - field `base_addr' is used before it's initialized. Move assignment of 'priv->base_addr` to the beginning, prior the call to mlxcpld_i2c_read_comm(). Wrong order caused the first read of capability register to be executed at wrong offset 0x0 instead of 0x2000. By chance it was a "good garbage" at 0x0 offset. Fixes: 313ce648b5a4 ("i2c: mlxcpld: Add support for extended transaction length for i2c-mlxcpld") Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
2019-05-27i2c: dev: fix potential memory leak in i2cdev_ioctl_rdwrYingjoe Chen
If I2C_M_RECV_LEN check failed, msgs[i].buf allocated by memdup_user will not be freed. Pump index up so it will be freed. Fixes: 838bfa6049fb ("i2c-dev: Add support for I2C_M_RECV_LEN") Signed-off-by: Yingjoe Chen <yingjoe.chen@mediatek.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-05-27RDMA/core: Fix panic when port_data isn't initializedKamal Heib
This happens if assign_name() returns failure when called from ib_register_device(), that will lead to the following panic in every time that someone touches the port_data's data members. BUG: unable to handle kernel NULL pointer dereference at 00000000000000c0 PGD 0 P4D 0 Oops: 0002 [#1] SMP PTI CPU: 19 PID: 1994 Comm: systemd-udevd Not tainted 5.1.0-rc5+ #1 Hardware name: HP ProLiant DL360p Gen8, BIOS P71 12/20/2013 RIP: 0010:_raw_spin_lock_irqsave+0x1e/0x40 Code: 85 ff 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 9c 58 66 66 90 66 90 48 89 c3 fa 66 66 90 66 66 90 31 c0 ba 01 00 00 00 <f0> 0f b1 17 0f 94 c2 84 d2 74 05 48 89 d8 5b c3 89 c6 e8 b4 85 8a RSP: 0018:ffffa8d7079a7c08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000202 RCX: ffffa8d7079a7bf8 RDX: 0000000000000001 RSI: ffff93607c990000 RDI: 00000000000000c0 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffc08c4dd8 R10: 0000000000000000 R11: 0000000000000001 R12: 00000000000000c0 R13: ffff93607c990000 R14: ffffffffc05a9740 R15: ffffa8d7079a7e98 FS: 00007f1c6ee438c0(0000) GS:ffff93609f6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 0000000819fca002 CR4: 00000000000606e0 Call Trace: free_netdevs+0x4d/0xe0 [ib_core] ib_dealloc_device+0x51/0xb0 [ib_core] __mlx5_ib_add+0x5e/0x70 [mlx5_ib] mlx5_add_device+0x57/0xe0 [mlx5_core] mlx5_register_interface+0x85/0xc0 [mlx5_core] ? 0xffffffffc0474000 do_one_initcall+0x4e/0x1d4 ? _cond_resched+0x15/0x30 ? kmem_cache_alloc_trace+0x15f/0x1c0 do_init_module+0x5a/0x218 load_module+0x186b/0x1e40 ? m_show+0x1c0/0x1c0 __do_sys_finit_module+0x94/0xe0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 8ceb1357b337 ("RDMA/device: Consolidate ib_device per_port data into one place") Signed-off-by: Kamal Heib <kamalheib1@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-05-27RDMA/uverbs: Pass udata on uverbs error unwindGal Pressman
When destroy_* is called as a result of uverbs create cleanup flow a cleared udata should be passed instead of NULL to indicate that it is called under user flow. Fixes: c4367a26357b ("IB: Pass uverbs_attr_bundle down ib_x destroy path") Signed-off-by: Gal Pressman <galpress@amazon.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-05-27RDMA/core: Clear out the udata before error unwindJason Gunthorpe
The core code should not pass a udata to the driver destroy function that contains the input from the create command. Otherwise the driver will attempt to interpret the create udata as destroy udata, and at least in the case of EFA, will leak resources. Zero this stuff out before invoking destroy. Reported-by: Leon Romanovsky <leonro@mellanox.com> Fixes: c4367a26357b ("IB: Pass uverbs_attr_bundle down ib_x destroy path") Reviewed-by: Gal Pressman <galpress@amazon.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-05-27Merge branch 'aquantia-fixes'David S. Miller
Igor Russkikh says: ==================== net: aquantia: various fixes May, 2019 Here is a set of various bug fixes found on recent verification stage. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-27net: aquantia: tcp checksum 0xffff being handled incorrectlyNikita Danilov
Thats a known quirk in windows tcp stack it can produce 0xffff checksum. Thats incorrect but it is. Atlantic HW with LRO enabled handles that incorrectly and changes csum to 0xfffe - but indicates that csum is invalid. This causes driver to pass packet to linux networking stack with CSUM_NONE, stack eventually drops the packet. There is a quirk in atlantic HW to enable correct processing of 0xffff incorrect csum. Enable it. The visible bug is that windows link partner with software generated csums caused TCP connection to be unstable since all packets that csum value are dropped. Reported-by: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com> Signed-off-by: Nikita Danilov <ndanilov@aquantia.com> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-27net: aquantia: fix LRO with FCS errorDmitry Bogdanov
Driver stops producing skbs on ring if a packet with FCS error was coalesced into LRO session. Ring gets hang forever. Thats a logical error in driver processing descriptors: When rx_stat indicates MAC Error, next pointer and eop flags are not filled. This confuses driver so it waits for descriptor 0 to be filled by HW. Solution is fill next pointer and eop flag even for packets with FCS error. Fixes: bab6de8fd180b ("net: ethernet: aquantia: Atlantic A0 and B0 specific functions.") Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com> Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-27net: aquantia: check rx csum for all packets in LRO sessionDmitry Bogdanov
Atlantic hardware does not aggregate nor breaks LRO sessions with bad csum packets. This means driver should take care of that. If in LRO session there is a non-first descriptor with invalid checksum (L2/L3/L4), the driver must account this information in csum application logic. Fixes: 018423e90bee8 ("net: ethernet: aquantia: Add ring support code") Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com> Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-27net: aquantia: tx clean budget logic errorIgor Russkikh
In case no other traffic happening on the ring, full tx cleanup may not be completed. That may cause socket buffer to overflow and tx traffic to stuck until next activity on the ring happens. This is due to logic error in budget variable decrementor. Variable is compared with zero, and then post decremented, causing it to become MAX_INT. Solution is remove decrementor from the `for` statement and rewrite it in a clear way. Fixes: b647d3980948e ("net: aquantia: Add tx clean budget and valid budget handling logic") Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-27vhost: scsi: add weight supportJason Wang
This patch will check the weight and exit the loop if we exceeds the weight. This is useful for preventing scsi kthread from hogging cpu which is guest triggerable. This addresses CVE-2019-3900. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Fixes: 057cbf49a1f0 ("tcm_vhost: Initial merge for vhost level target fabric driver") Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-05-27vhost: vsock: add weight supportJason Wang
This patch will check the weight and exit the loop if we exceeds the weight. This is useful for preventing vsock kthread from hogging cpu which is guest triggerable. The weight can help to avoid starving the request from on direction while another direction is being processed. The value of weight is picked from vhost-net. This addresses CVE-2019-3900. Cc: Stefan Hajnoczi <stefanha@redhat.com> Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko") Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-05-27vhost_net: fix possible infinite loopJason Wang
When the rx buffer is too small for a packet, we will discard the vq descriptor and retry it for the next packet: while ((sock_len = vhost_net_rx_peek_head_len(net, sock->sk, &busyloop_intr))) { ... /* On overrun, truncate and discard */ if (unlikely(headcount > UIO_MAXIOV)) { iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1); err = sock->ops->recvmsg(sock, &msg, 1, MSG_DONTWAIT | MSG_TRUNC); pr_debug("Discarded rx packet: len %zd\n", sock_len); continue; } ... } This makes it possible to trigger a infinite while..continue loop through the co-opreation of two VMs like: 1) Malicious VM1 allocate 1 byte rx buffer and try to slow down the vhost process as much as possible e.g using indirect descriptors or other. 2) Malicious VM2 generate packets to VM1 as fast as possible Fixing this by checking against weight at the end of RX and TX loop. This also eliminate other similar cases when: - userspace is consuming the packets in the meanwhile - theoretical TOCTOU attack if guest moving avail index back and forth to hit the continue after vhost find guest just add new buffers This addresses CVE-2019-3900. Fixes: d8316f3991d20 ("vhost: fix total length when packets are too short") Fixes: 3a4d5c94e9593 ("vhost_net: a kernel-level virtio server") Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-05-27vhost: introduce vhost_exceeds_weight()Jason Wang
We used to have vhost_exceeds_weight() for vhost-net to: - prevent vhost kthread from hogging the cpu - balance the time spent between TX and RX This function could be useful for vsock and scsi as well. So move it to vhost.c. Device must specify a weight which counts the number of requests, or it can also specific a byte_weight which counts the number of bytes that has been processed. Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-05-27virtio: Fix indentation of VIRTIO_MMIOFabrizio Castro
VIRTIO_MMIO config option block starts with a space, fix that. Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-05-27virtio: add unlikely() to WARN_ON_ONCE()Igor Stoppa
The condition to test is unlikely() to be true. Add the hint. Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Virtualization@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-05-27iommu/vt-d: Set the right field for Page Walk SnoopLu Baolu
Set the page walk snoop to the right bit, otherwise the domain id field will be overlapped. Reported-by: Dave Jiang <dave.jiang@intel.com> Fixes: 6f7db75e1c469 ("iommu/vt-d: Add second level page table interface") Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-05-27iommu/vt-d: Fix lock inversion between iommu->lock and device_domain_lockDave Jiang
Lockdep debug reported lock inversion related with the iommu code caused by dmar_insert_one_dev_info() grabbing the iommu->lock and the device_domain_lock out of order versus the code path in iommu_flush_dev_iotlb(). Expanding the scope of the iommu->lock and reversing the order of lock acquisition fixes the issue. [ 76.238180] dsa_bus wq0.0: dsa wq wq0.0 disabled [ 76.248706] [ 76.250486] ======================================================== [ 76.257113] WARNING: possible irq lock inversion dependency detected [ 76.263736] 5.1.0-rc5+ #162 Not tainted [ 76.267854] -------------------------------------------------------- [ 76.274485] systemd-journal/521 just changed the state of lock: [ 76.280685] 0000000055b330f5 (device_domain_lock){..-.}, at: iommu_flush_dev_iotlb.part.63+0x29/0x90 [ 76.290099] but this lock took another, SOFTIRQ-unsafe lock in the past: [ 76.297093] (&(&iommu->lock)->rlock){+.+.} [ 76.297094] [ 76.297094] [ 76.297094] and interrupts could create inverse lock ordering between them. [ 76.297094] [ 76.314257] [ 76.314257] other info that might help us debug this: [ 76.321448] Possible interrupt unsafe locking scenario: [ 76.321448] [ 76.328907] CPU0 CPU1 [ 76.333777] ---- ---- [ 76.338642] lock(&(&iommu->lock)->rlock); [ 76.343165] local_irq_disable(); [ 76.349422] lock(device_domain_lock); [ 76.356116] lock(&(&iommu->lock)->rlock); [ 76.363154] <Interrupt> [ 76.366134] lock(device_domain_lock); [ 76.370548] [ 76.370548] *** DEADLOCK *** Fixes: 745f2586e78e ("iommu/vt-d: Simplify function get_domain_for_dev()") Signed-off-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-05-27iommu: Add missing new line for dma typeLu Baolu
So that all types are printed in the same format. Fixes: c52c72d3dee81 ("iommu: Add sysfs attribyte for domain type") Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-05-27drm/etnaviv: lock MMU while dumping coreLucas Stach
The devcoredump needs to operate on a stable state of the MMU while it is writing the MMU state to the coredump. The missing lock allowed both the userspace submit, as well as the GPU job finish paths to mutate the MMU state while a coredump is under way. Fixes: a8c21a5451d8 (drm/etnaviv: add initial etnaviv DRM driver) Reported-by: David Jander <david@protonic.nl> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: David Jander <david@protonic.nl> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-05-27block: Don't revalidate bdev of hidden gendiskJan Kara
When hidden gendisk is revalidated, there's no point in revalidating associated block device as there's none. We would thus just create new bdev inode, report "detected capacity change from 0 to XXX" message and evict the bdev inode again. Avoid this pointless dance and confusing message in the kernel log. Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-05-27loop: Don't change loop device under exclusive openerJan Kara
Loop module allows calling LOOP_SET_FD while there are other openers of the loop device. Even exclusive ones. This can lead to weird consequences such as kernel deadlocks like: mount_bdev() lo_ioctl() udf_fill_super() udf_load_vrs() sb_set_blocksize() - sets desired block size B udf_tread() sb_bread() __bread_gfp(bdev, block, B) loop_set_fd() set_blocksize() - now __getblk_slow() indefinitely loops because B != bdev block size Fix the problem by disallowing LOOP_SET_FD ioctl when there are exclusive openers of a loop device. [Deliberately chosen not to CC stable as a user with priviledges to trigger this race has other means of taking the system down and this has a potential of breaking some weird userspace setup] Reported-and-tested-by: syzbot+10007d66ca02b08f0e60@syzkaller.appspotmail.com Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-05-27drm/imx: ipuv3-plane: fix atomic update status query for non-plus i.MX6QPhilipp Zabel
The current buffer check halves the frame rate on non-plus i.MX6Q, as the IDMAC current buffer pointer is not yet updated when ipu_plane_atomic_update_pending is called from the EOF irq handler. Fixes: 70e8a0c71e9 ("drm/imx: ipuv3-plane: add function to query atomic update status") Tested-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Cc: stable@vger.kernel.org
2019-05-27drm/qxl: drop WARN_ONCE()Gerd Hoffmann
There is no good reason to flood the kernel log with a WARN stacktrace just because someone tried to mmap a prime buffer. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20190524104251.22761-1-kraxel@redhat.com
2019-05-27fuse: add FUSE_WRITE_KILL_PRIVMiklos Szeredi
In the FOPEN_DIRECT_IO case the write path doesn't call file_remove_privs() and that means setuid bit is not cleared if unpriviliged user writes to a file with setuid bit set. pjdfstest chmod test 12.t tests this and fails. Fix this by adding a flag to the FUSE_WRITE message that requests clearing privileges on the given file. This needs This better than just calling fuse_remove_privs(), because the attributes may not be up to date, so in that case a write may miss clearing the privileges. Test case: $ passthrough_ll /mnt/pasthrough-mnt -o default_permissions,allow_other,cache=never $ mkdir /mnt/pasthrough-mnt/testdir $ cd /mnt/pasthrough-mnt/testdir $ prove -rv pjdfstests/tests/chmod/12.t Reported-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Tested-by: Vivek Goyal <vgoyal@redhat.com>
2019-05-27fuse: fallocate: fix return with locked inodeMiklos Szeredi
Do the proper cleanup in case the size check fails. Tested with xfstests:generic/228 Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 0cbade024ba5 ("fuse: honor RLIMIT_FSIZE in fuse_file_fallocate") Cc: Liu Bo <bo.liu@linux.alibaba.com> Cc: <stable@vger.kernel.org> # v3.5 Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2019-05-27Merge tag 'intel-pinctrl-v5.2-2' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into fixes intel-pinctrl for v5.2-2 Fix a laggish ELAN touchpad responsiveness due to an odd interrupt masking. The following is an automated git shortlog grouped by driver: intel: - Clear interrupt status in mask/unmask callback - Use GENMASK() consistently
generated by cgit (git 2.34.1) at 2025-09-18 22:59:20 +0000