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-28rtw88: Make some symbols staticYueHaibing
Fix sparse warnings: drivers/net/wireless/realtek/rtw88/phy.c:851:4: warning: symbol 'rtw_cck_size' was not declared. Should it be static? drivers/net/wireless/realtek/rtw88/phy.c:852:4: warning: symbol 'rtw_ofdm_size' was not declared. Should it be static? drivers/net/wireless/realtek/rtw88/phy.c:853:4: warning: symbol 'rtw_ht_1s_size' was not declared. Should it be static? drivers/net/wireless/realtek/rtw88/phy.c:854:4: warning: symbol 'rtw_ht_2s_size' was not declared. Should it be static? drivers/net/wireless/realtek/rtw88/phy.c:855:4: warning: symbol 'rtw_vht_1s_size' was not declared. Should it be static? drivers/net/wireless/realtek/rtw88/phy.c:856:4: warning: symbol 'rtw_vht_2s_size' was not declared. Should it be static? drivers/net/wireless/realtek/rtw88/fw.c:11:6: warning: symbol 'rtw_fw_c2h_cmd_handle_ext' was not declared. Should it be static? drivers/net/wireless/realtek/rtw88/fw.c:50:6: warning: symbol 'rtw_fw_send_h2c_command' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-05-28rtw88: avoid circular locking between local->iflist_mtx and rtwdev->mutexStanislaw Gruszka
Remove circular lock dependency by using atomic version of interfaces iterate in watch_dog_work(), hence avoid taking local->iflist_mtx (rtw_vif_watch_dog_iter() only update some data, it can be called from atomic context). Fixes below LOCKDEP warning: [ 1157.219415] ====================================================== [ 1157.225772] [ INFO: possible circular locking dependency detected ] [ 1157.232150] 3.10.0-1043.el7.sgruszka1.x86_64.debug #1 Not tainted [ 1157.238346] ------------------------------------------------------- [ 1157.244635] kworker/u4:2/14490 is trying to acquire lock: [ 1157.250194] (&rtwdev->mutex){+.+.+.}, at: [<ffffffffc098322b>] rtw_ops_config+0x2b/0x90 [rtw88] [ 1157.259151] but task is already holding lock: [ 1157.265085] (&local->iflist_mtx){+.+...}, at: [<ffffffffc0b8ab7a>] ieee80211_mgd_probe_ap.part.28+0xca/0x160 [mac80211] [ 1157.276169] which lock already depends on the new lock. [ 1157.284488] the existing dependency chain (in reverse order) is: [ 1157.292101] -> #2 (&local->iflist_mtx){+.+...}: [ 1157.296919] [<ffffffffbc741a29>] lock_acquire+0x99/0x1e0 [ 1157.302955] [<ffffffffbce72793>] mutex_lock_nested+0x93/0x410 [ 1157.309416] [<ffffffffc0b6038f>] ieee80211_iterate_interfaces+0x2f/0x60 [mac80211] [ 1157.317730] [<ffffffffc09811ab>] rtw_watch_dog_work+0xcb/0x130 [rtw88] [ 1157.325003] [<ffffffffbc6d77bc>] process_one_work+0x22c/0x720 [ 1157.331481] [<ffffffffbc6d7dd6>] worker_thread+0x126/0x3b0 [ 1157.337589] [<ffffffffbc6e107f>] kthread+0xef/0x100 [ 1157.343260] [<ffffffffbce848b7>] ret_from_fork_nospec_end+0x0/0x39 [ 1157.350091] -> #1 ((&(&rtwdev->watch_dog_work)->work)){+.+...}: [ 1157.356314] [<ffffffffbc741a29>] lock_acquire+0x99/0x1e0 [ 1157.362427] [<ffffffffbc6d570b>] flush_work+0x5b/0x310 [ 1157.368287] [<ffffffffbc6d740e>] __cancel_work_timer+0xae/0x170 [ 1157.374940] [<ffffffffbc6d7583>] cancel_delayed_work_sync+0x13/0x20 [ 1157.381930] [<ffffffffc0982b49>] rtw_core_stop+0x29/0x50 [rtw88] [ 1157.388679] [<ffffffffc098bee6>] rtw_enter_ips+0x16/0x20 [rtw88] [ 1157.395428] [<ffffffffc0983242>] rtw_ops_config+0x42/0x90 [rtw88] [ 1157.402173] [<ffffffffc0b13343>] ieee80211_hw_config+0xc3/0x680 [mac80211] [ 1157.409854] [<ffffffffc0b3925b>] ieee80211_do_open+0x69b/0x9c0 [mac80211] [ 1157.417418] [<ffffffffc0b395e9>] ieee80211_open+0x69/0x70 [mac80211] [ 1157.424496] [<ffffffffbcd03442>] __dev_open+0xe2/0x160 [ 1157.430356] [<ffffffffbcd03773>] __dev_change_flags+0xa3/0x180 [ 1157.436922] [<ffffffffbcd03879>] dev_change_flags+0x29/0x60 [ 1157.443224] [<ffffffffbcda14c4>] devinet_ioctl+0x794/0x890 [ 1157.449331] [<ffffffffbcda27b5>] inet_ioctl+0x75/0xa0 [ 1157.455087] [<ffffffffbccd54eb>] sock_do_ioctl+0x2b/0x60 [ 1157.461178] [<ffffffffbccd5753>] sock_ioctl+0x233/0x310 [ 1157.467109] [<ffffffffbc8bd820>] do_vfs_ioctl+0x410/0x6c0 [ 1157.473233] [<ffffffffbc8bdb71>] SyS_ioctl+0xa1/0xc0 [ 1157.478914] [<ffffffffbce84a5e>] system_call_fastpath+0x25/0x2a [ 1157.485569] -> #0 (&rtwdev->mutex){+.+.+.}: [ 1157.490022] [<ffffffffbc7409d1>] __lock_acquire+0xec1/0x1630 [ 1157.496305] [<ffffffffbc741a29>] lock_acquire+0x99/0x1e0 [ 1157.502413] [<ffffffffbce72793>] mutex_lock_nested+0x93/0x410 [ 1157.508890] [<ffffffffc098322b>] rtw_ops_config+0x2b/0x90 [rtw88] [ 1157.515724] [<ffffffffc0b13343>] ieee80211_hw_config+0xc3/0x680 [mac80211] [ 1157.523370] [<ffffffffc0b8a4ca>] ieee80211_recalc_ps.part.27+0x9a/0x180 [mac80211] [ 1157.531685] [<ffffffffc0b8abc5>] ieee80211_mgd_probe_ap.part.28+0x115/0x160 [mac80211] [ 1157.540353] [<ffffffffc0b8b40d>] ieee80211_beacon_connection_loss_work+0x4d/0x80 [mac80211] [ 1157.549513] [<ffffffffbc6d77bc>] process_one_work+0x22c/0x720 [ 1157.555886] [<ffffffffbc6d7dd6>] worker_thread+0x126/0x3b0 [ 1157.562170] [<ffffffffbc6e107f>] kthread+0xef/0x100 [ 1157.567765] [<ffffffffbce848b7>] ret_from_fork_nospec_end+0x0/0x39 [ 1157.574579] other info that might help us debug this: [ 1157.582788] Chain exists of: &rtwdev->mutex --> (&(&rtwdev->watch_dog_work)->work) --> &local->iflist_mtx [ 1157.593024] Possible unsafe locking scenario: [ 1157.599046] CPU0 CPU1 [ 1157.603653] ---- ---- [ 1157.608258] lock(&local->iflist_mtx); [ 1157.612180] lock((&(&rtwdev->watch_dog_work)->work)); [ 1157.620074] lock(&local->iflist_mtx); [ 1157.626555] lock(&rtwdev->mutex); [ 1157.630124] *** DEADLOCK *** [ 1157.636148] 4 locks held by kworker/u4:2/14490: [ 1157.640755] #0: (%s#6){.+.+.+}, at: [<ffffffffbc6d774a>] process_one_work+0x1ba/0x720 [ 1157.648965] #1: ((&ifmgd->beacon_connection_loss_work)){+.+.+.}, at: [<ffffffffbc6d774a>] process_one_work+0x1ba/0x720 [ 1157.659950] #2: (&wdev->mtx){+.+.+.}, at: [<ffffffffc0b8aad5>] ieee80211_mgd_probe_ap.part.28+0x25/0x160 [mac80211] [ 1157.670901] #3: (&local->iflist_mtx){+.+...}, at: [<ffffffffc0b8ab7a>] ieee80211_mgd_probe_ap.part.28+0xca/0x160 [mac80211] [ 1157.682466] Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-05-28rsi: Properly initialize data in rsi_sdio_ta_resetNathan Chancellor
When building with -Wuninitialized, Clang warns: drivers/net/wireless/rsi/rsi_91x_sdio.c:940:43: warning: variable 'data' is uninitialized when used here [-Wuninitialized] put_unaligned_le32(TA_HOLD_THREAD_VALUE, data); ^~~~ drivers/net/wireless/rsi/rsi_91x_sdio.c:930:10: note: initialize the variable 'data' to silence this warning u8 *data; ^ = NULL 1 warning generated. Using Clang's suggestion of initializing data to NULL wouldn't work out because data will be dereferenced by put_unaligned_le32. Use kzalloc to properly initialize data, which matches a couple of other places in this driver. Fixes: e5a1ecc97e5f ("rsi: add firmware loading for 9116 device") Link: https://github.com/ClangBuiltLinux/linux/issues/464 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-05-28rtw88: fix unassigned rssi_level in rtw_sta_infoYan-Hsuan Chuang
The new rssi_level should be stored in si, otherwise the rssi_level will never be updated and get a wrong RA mask, which is calculated by the rssi level If a wrong RA mask is chosen, the firmware will pick some *bad rates*. The most hurtful scene will be in *noisy environment*, such as office or public area with many APs and users. The latency would be high and the overall throughput would be only half or less. Tested in 2.4G in office area, with this patch the throughput increased from such as "1x Mbps -> 4x Mbps". Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-05-28rtw88: fix subscript above array bounds compiler warningStanislaw Gruszka
My compiler complains about: drivers/net/wireless/realtek/rtw88/phy.c: In function ‘rtw_phy_rf_power_2_rssi’: drivers/net/wireless/realtek/rtw88/phy.c:430:26: warning: array subscript is above array bounds [-Warray-bounds] linear = db_invert_table[i][j]; According to comment power_db should be in range 1 ~ 96 . To fix add check for boundaries before access the array. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
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-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-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
2019-05-27PCI: PM: Avoid possible suspend-to-idle issueRafael J. Wysocki
If a PCI driver leaves the device handled by it in D0 and calls pci_save_state() on the device in its ->suspend() or ->suspend_late() callback, it can expect the device to stay in D0 over the whole s2idle cycle. However, that may not be the case if there is a spurious wakeup while the system is suspended, because in that case pci_pm_suspend_noirq() will run again after pci_pm_resume_noirq() which calls pci_restore_state(), via pci_pm_default_resume_early(), so state_saved is cleared and the second iteration of pci_pm_suspend_noirq() will invoke pci_prepare_to_sleep() which may change the power state of the device. To avoid that, add a new internal flag, skip_bus_pm, that will be set by pci_pm_suspend_noirq() when it runs for the first time during the given system suspend-resume cycle if the state of the device has been saved already and the device is still in D0. Setting that flag will cause the next iterations of pci_pm_suspend_noirq() to set state_saved for pci_pm_resume_noirq(), so that it always restores the device state from the originally saved data, and avoid calling pci_prepare_to_sleep() for the device. Fixes: 33e4f80ee69b ("ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Keith Busch <keith.busch@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-05-27ACPI: PM: Call pm_set_suspend_via_firmware() during hibernationRafael J. Wysocki
On systems with ACPI platform firmware the last stage of hibernation is analogous to system suspend to S3 (suspend-to-RAM), so it should be handled analogously. In particular, pm_suspend_via_firmware() should return 'true' in that stage to let the callers of it know that control will be passed to the platform firmware going forward, so pm_set_suspend_via_firmware() needs to be called then in analogy with acpi_suspend_begin(). However, the platform hibernation ->begin() callback is invoked during the "freeze" transition (before creating a snapshot image of system memory) as well as during the "hibernate" transition which is the last stage of it and pm_set_suspend_via_firmware() should be invoked by that callback in the latter stage only. In order to implement that redefine the hibernation ->begin() callback to take a pm_message_t argument to indicate which stage of hibernation is taking place and rework acpi_hibernation_begin() and acpi_hibernation_begin_old() to take it into account as needed. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-05-27ACPI/PCI: PM: Add missing wakeup.flags.valid checksRafael J. Wysocki
Both acpi_pci_need_resume() and acpi_dev_needs_resume() check if the current ACPI wakeup configuration of the device matches what is expected as far as system wakeup from sleep states is concerned, as reflected by the device_may_wakeup() return value for the device. However, they only should do that if wakeup.flags.valid is set for the device's ACPI companion, because otherwise the wakeup.prepare_count value for it is meaningless. Add the missing wakeup.flags.valid checks to these functions. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-05-27ovl: support the FS_IOC_FS[SG]ETXATTR ioctlsAmir Goldstein
They are the extended version of FS_IOC_FS[SG]ETFLAGS ioctls. xfs_io -c "chattr <flags>" uses the new ioctls for setting flags. This used to work in kernel pre v4.19, before stacked file ops introduced the ovl_ioctl whitelist. Reported-by: Dave Chinner <david@fromorbit.com> Fixes: d1d04ef8572b ("ovl: stack file ops") Cc: <stable@vger.kernel.org> # v4.19 Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2019-05-26net: tulip: de4x5: Drop redundant MODULE_DEVICE_TABLE()Kees Cook
Building with Clang reports the redundant use of MODULE_DEVICE_TABLE(): drivers/net/ethernet/dec/tulip/de4x5.c:2110:1: error: redefinition of '__mod_eisa__de4x5_eisa_ids_device_table' MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids); ^ ./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE' extern typeof(name) __mod_##type##__##name##_device_table \ ^ <scratch space>:90:1: note: expanded from here __mod_eisa__de4x5_eisa_ids_device_table ^ drivers/net/ethernet/dec/tulip/de4x5.c:2100:1: note: previous definition is here MODULE_DEVICE_TABLE(eisa, de4x5_eisa_ids); ^ ./include/linux/module.h:229:21: note: expanded from macro 'MODULE_DEVICE_TABLE' extern typeof(name) __mod_##type##__##name##_device_table \ ^ <scratch space>:85:1: note: expanded from here __mod_eisa__de4x5_eisa_ids_device_table ^ This drops the one further from the table definition to match the common use of MODULE_DEVICE_TABLE(). Fixes: 07563c711fbc ("EISA bus MODALIAS attributes support") Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-26Merge branch 'net-tls-two-fixes-for-rx_list-pre-handling'David S. Miller
Jakub Kicinski says: ==================== net/tls: two fixes for rx_list pre-handling tls_sw_recvmsg() had been modified to cater better to async decrypt. Partially read records now live on the rx_list. Data is copied from this list before the old do {} while loop, and the not included correctly in deciding whether to sleep or not and lowat threshold handling. These modifications, unfortunately, added some bugs. First patch fixes lowat - we need to calculate the threshold early and make sure all copied data is compared to the threshold, not just the freshly decrypted data. Third patch fixes sleep - if data is picked up from rx_list and no flags are set, we should not put the process to sleep, but rather return the partial read. Patches 2 and 4 add test cases for these bugs, both will cause a sleep and test timeout before the fix. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-26selftests/tls: add test for sleeping even though there is dataJakub Kicinski
Add a test which sends 15 bytes of data, and then tries to read 10 byes twice. Previously the second read would sleep indifinitely, since the record was already decrypted and there is only 5 bytes left, not full 10. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-26net/tls: fix no wakeup on partial readsJakub Kicinski
When tls_sw_recvmsg() partially copies a record it pops that record from ctx->recv_pkt and places it on rx_list. Next iteration of tls_sw_recvmsg() reads from rx_list via process_rx_list() before it enters the decryption loop. If there is no more records to be read tls_wait_data() will put the process on the wait queue and got to sleep. This is incorrect, because some data was already copied in process_rx_list(). In case of RPC connections process may never get woken up, because peer also simply blocks in read(). I think this may also fix a similar issue when BPF is at play, because after __tcp_bpf_recvmsg() returns some data we subtract it from len and use continue to restart the loop, but len could have just reached 0, so again we'd sleep unnecessarily. That's added by: commit d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records") Reported-by: David Beckett <david.beckett@netronome.com> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Tested-by: David Beckett <david.beckett@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-26selftests/tls: test for lowat overshoot with multiple recordsJakub Kicinski
Set SO_RCVLOWAT and test it gets respected when gathering data from multiple records. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-26net/tls: fix lowat calculation if some data came from previous recordJakub Kicinski
If some of the data came from the previous record, i.e. from the rx_list it had already been decrypted, so it's not counted towards the "decrypted" variable, but the "copied" variable. Take that into account when checking lowat. When calculating lowat target we need to pass the original len. E.g. if lowat is at 80, len is 100 and we had 30 bytes on rx_list target would currently be incorrectly calculated as 70, even though we only need 50 more bytes to make up the 80. Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com> Tested-by: David Beckett <david.beckett@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-26Linux 5.2-rc2v5.2-rc2Linus Torvalds
2019-05-26Merge tag 'trace-v5.2-rc1-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing warning fix from Steven Rostedt: "Make the GCC 9 warning for sub struct memset go away. GCC 9 now warns about calling memset() on partial structures when it goes across multiple fields. This adds a helper for the place in tracing that does this type of clearing of a structure" * tag 'trace-v5.2-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Silence GCC 9 array bounds warning
2019-05-26Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull KVM fixes from Paolo Bonzini: "The usual smattering of fixes and tunings that came in too late for the merge window, but should not wait four months before they appear in a release. I also travelled a bit more than usual in the first part of May, which didn't help with picking up patches and reports promptly" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (33 commits) KVM: x86: fix return value for reserved EFER tools/kvm_stat: fix fields filter for child events KVM: selftests: Wrap vcpu_nested_state_get/set functions with x86 guard kvm: selftests: aarch64: compile with warnings on kvm: selftests: aarch64: fix default vm mode kvm: selftests: aarch64: dirty_log_test: fix unaligned memslot size KVM: s390: fix memory slot handling for KVM_SET_USER_MEMORY_REGION KVM: x86/pmu: do not mask the value that is written to fixed PMUs KVM: x86/pmu: mask the result of rdpmc according to the width of the counters x86/kvm/pmu: Set AMD's virt PMU version to 1 KVM: x86: do not spam dmesg with VMCS/VMCB dumps kvm: Check irqchip mode before assign irqfd kvm: svm/avic: fix off-by-one in checking host APIC ID KVM: selftests: do not blindly clobber registers in guest asm KVM: selftests: Remove duplicated TEST_ASSERT in hyperv_cpuid.c KVM: LAPIC: Expose per-vCPU timer_advance_ns to userspace KVM: LAPIC: Fix lapic_timer_advance_ns parameter overflow kvm: vmx: Fix -Wmissing-prototypes warnings KVM: nVMX: Fix using __this_cpu_read() in preemptible context kvm: fix compilation on s390 ...
generated by cgit (git 2.34.1) at 2025-09-12 23:25:49 +0000