aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-01-16staging: wfx: simplify hif_set_arp_ipv4_filter() usageJérôme Pouiller2-21/+20
The structure hif_mib_arp_ip_addr_table come from hardware API. It is not intended to be manipulated in upper layers of the driver. In add, current code for hif_set_arp_ipv4_filter() is too dumb. It should pack data using the hardware representation instead of leaving all work to the caller. Signed-off-by: Jérôme Pouiller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-16staging: wfx: simplify hif_set_rcpi_rssi_threshold() usageJérôme Pouiller2-26/+19
The structure hif_mib_rcpi_rssi_threshold come from hardware API. It is not intended to be manipulated in upper layers of the driver. In add, current code for hif_set_rcpi_rssi_threshold() is dumb. It should pack data using the hardware representation instead of leaving all work to the caller. Signed-off-by: Jérôme Pouiller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-16staging: wfx: simplify hif_set_output_power() usageJérôme Pouiller3-7/+9
Hardware API use 10th of dBm for output power unit. Upper layers should use same units than mac80211 and the conversion should be done by low level layer of the driver (hif_set_output_power()) In add, current code of hif_set_output_power() use a __le32 while the device API specify a specific structure for this. Signed-off-by: Jérôme Pouiller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-16staging: wfx: simplify hif_set_tx_rate_retry_policy() usageJérôme Pouiller4-19/+23
The structure hif_mib_set_tx_rate_retry_policy come from hardware API. It is not intended to be manipulated in upper layers of the driver. So, this patch relocate handling of this structure to hif_set_tx_rate_retry_policy() (the low level function). Signed-off-by: Jérôme Pouiller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-16staging: wfx: send rate policies one by oneJérôme Pouiller1-28/+25
Rate policies (aka. tx_rate_retry_policy in hardware API) are sent to device asynchronously from tx requests. So, the device maintains a list of active rate policies and the tx requests only reference an existent rate policy. The device API allows to send multiple rate policies at once. However, this property is very rarely used. We prefer to send rate policies one by one and simplify the architecture. Signed-off-by: Jérôme Pouiller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-16staging: wfx: add missing PROBE_RESP_OFFLOAD featureJérôme Pouiller1-0/+5
Some userspace tools (hostapd) rely on probe_resp_offload fields for certain features. Signed-off-by: Jérôme Pouiller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-16staging: wfx: make hif_scan() usage clearerJérôme Pouiller1-4/+3
hif_scan() return max number of jiffies to wait before the completion indication. However, if this value is negative, an error has occurred. Reword the code to reflect that behavior. Signed-off-by: Jérôme Pouiller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-16staging: wfx: revert unexpected change in debugfs outputJérôme Pouiller1-1/+1
It appears that commit 8c7128c4cf4e ("staging: align to fix warnings of line over 80 characters") do slightly more than what is explained in commit log. Especially, it changes the output of the file rx_stats from debugfs. From some point of view, this file can be considered as a part of the API. Any change on it should be clearly announced. Since the change introduced does not seems to have any justification, revert it. Reported-by: Pascal Prime <[email protected]> Cc: Jules Irenge <[email protected]> Fixes: 8c7128c4cf4e ("staging: align to fix warnings of line over 80 characters") Signed-off-by: Jérôme Pouiller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-16staging: most: remove header include path to drivers/stagingMasahiro Yamada17-17/+15
There is no need to add "ccflags-y += -I $(srctree)/drivers/staging" just for including <most/most.h>. Use the #include "..." directive with the correct relative path. Signed-off-by: Masahiro Yamada <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-16x86/CPU/AMD: Ensure clearing of SME/SEV features is maintainedTom Lendacky1-2/+2
If the SME and SEV features are present via CPUID, but memory encryption support is not enabled (MSR 0xC001_0010[23]), the feature flags are cleared using clear_cpu_cap(). However, if get_cpu_cap() is later called, these feature flags will be reset back to present, which is not desired. Change from using clear_cpu_cap() to setup_clear_cpu_cap() so that the clearing of the flags is maintained. Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: <[email protected]> # 4.16.x- Link: https://lkml.kernel.org/r/226de90a703c3c0be5a49565047905ac4e94e8f3.1579125915.git.thomas.lendacky@amd.com
2020-01-16Merge tag 'tag-chrome-platform-fixes-for-v5.5-rc7' of ↵Linus Torvalds1-8/+20
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux Pull chrome platform fix from Benson Leung: "One fix in the wilco_ec keyboard backlight driver to allow the EC driver to continue loading in the absence of a backlight module" * tag 'tag-chrome-platform-fixes-for-v5.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: wilco_ec: Fix keyboard backlight probing
2020-01-16USB: serial: option: add support for Quectel RM500Q in QDL modeReinhard Speyerer1-0/+2
Add support for Quectel RM500Q in QDL mode. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 24 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0800 Rev= 0.00 S: Manufacturer=Qualcomm CDMA Technologies MSM S: Product=QUSB_BULK_SN:xxxxxxxx S: SerialNumber=xxxxxxxx C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 2mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms It is assumed that the ZLP flag required for other Qualcomm-based 5G devices also applies to Quectel RM500Q. Signed-off-by: Reinhard Speyerer <[email protected]> Cc: stable <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2020-01-16netfilter: nat: fix ICMP header corruption on ICMP errorsEyal Birger1-0/+13
Commit 8303b7e8f018 ("netfilter: nat: fix spurious connection timeouts") made nf_nat_icmp_reply_translation() use icmp_manip_pkt() as the l4 manipulation function for the outer packet on ICMP errors. However, icmp_manip_pkt() assumes the packet has an 'id' field which is not correct for all types of ICMP messages. This is not correct for ICMP error packets, and leads to bogus bytes being written the ICMP header, which can be wrongfully regarded as 'length' bytes by RFC 4884 compliant receivers. Fix by assigning the 'id' field only for ICMP messages that have this semantic. Reported-by: Shmulik Ladkani <[email protected]> Fixes: 8303b7e8f018 ("netfilter: nat: fix spurious connection timeouts") Signed-off-by: Eyal Birger <[email protected]> Acked-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-01-16net: wan: lapbether.c: Use built-in RCU list checkingMadhuparna Bhowmik1-1/+1
The only callers of the function lapbeth_get_x25_dev() are lapbeth_rcv() and lapbeth_device_event(). lapbeth_rcv() uses rcu_read_lock() whereas lapbeth_device_event() is called with RTNL held (As mentioned in the comments). Therefore, pass lockdep_rtnl_is_held() as cond argument in list_for_each_entry_rcu(); Signed-off-by: Madhuparna Bhowmik <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-16netfilter: nf_tables: fix flowtable list del corruptionFlorian Westphal1-0/+6
syzbot reported following crash: list_del corruption, ffff88808c9bb000->prev is LIST_POISON2 (dead000000000122) [..] Call Trace: __list_del_entry include/linux/list.h:131 [inline] list_del_rcu include/linux/rculist.h:148 [inline] nf_tables_commit+0x1068/0x3b30 net/netfilter/nf_tables_api.c:7183 [..] The commit transaction list has: NFT_MSG_NEWTABLE NFT_MSG_NEWFLOWTABLE NFT_MSG_DELFLOWTABLE NFT_MSG_DELTABLE A missing generation check during DELTABLE processing causes it to queue the DELFLOWTABLE operation a second time, so we corrupt the list here: case NFT_MSG_DELFLOWTABLE: list_del_rcu(&nft_trans_flowtable(trans)->list); nf_tables_flowtable_notify(&trans->ctx, because we have two different DELFLOWTABLE transactions for the same flowtable. We then call list_del_rcu() twice for the same flowtable->list. The object handling seems to suffer from the same bug so add a generation check too and only queue delete transactions for flowtables/objects that are still active in the next generation. Reported-by: [email protected] Fixes: 3b49e2e94e6eb ("netfilter: nf_tables: add flow table netlink frontend") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-01-16netfilter: nf_tables: fix memory leak in nf_tables_parse_netdev_hooks()Dan Carpenter1-0/+1
Syzbot detected a leak in nf_tables_parse_netdev_hooks(). If the hook already exists, then the error handling doesn't free the newest "hook". Reported-by: [email protected] Fixes: b75a3e8371bc ("netfilter: nf_tables: allow netdevice to be used only once per flowtable") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-01-16netfilter: nf_tables: remove WARN and add NLA_STRING upper limitsFlorian Westphal1-4/+9
This WARN can trigger because some of the names fed to the module autoload function can be of arbitrary length. Remove the WARN and add limits for all NLA_STRING attributes. Reported-by: [email protected] Fixes: 452238e8d5ffd8 ("netfilter: nf_tables: add and use helper for module autoload") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-01-16netfilter: nft_tunnel: ERSPAN_VERSION must not be nullFlorian Westphal1-0/+3
Fixes: af308b94a2a4a5 ("netfilter: nf_tables: add tunnel support") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-01-16netfilter: nft_tunnel: fix null-attribute checkFlorian Westphal1-1/+1
else we get null deref when one of the attributes is missing, both must be non-null. Reported-by: [email protected] Fixes: aaecfdb5c5dd8ba ("netfilter: nf_tables: match on tunnel metadata") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-01-16netfilter: nf_tables: store transaction list locally while requesting modulePablo Neira Ayuso1-9/+10
This patch fixes a WARN_ON in nft_set_destroy() due to missing set reference count drop from the preparation phase. This is triggered by the module autoload path. Do not exercise the abort path from nft_request_module() while preparation phase cleaning up is still pending. WARNING: CPU: 3 PID: 3456 at net/netfilter/nf_tables_api.c:3740 nft_set_destroy+0x45/0x50 [nf_tables] [...] CPU: 3 PID: 3456 Comm: nft Not tainted 5.4.6-arch3-1 #1 RIP: 0010:nft_set_destroy+0x45/0x50 [nf_tables] Code: e8 30 eb 83 c6 48 8b 85 80 00 00 00 48 8b b8 90 00 00 00 e8 dd 6b d7 c5 48 8b 7d 30 e8 24 dd eb c5 48 89 ef 5d e9 6b c6 e5 c5 <0f> 0b c3 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 7f 10 e9 52 RSP: 0018:ffffac4f43e53700 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffff99d63a154d80 RCX: 0000000001f88e03 RDX: 0000000001f88c03 RSI: ffff99d6560ef0c0 RDI: ffff99d63a101200 RBP: ffff99d617721de0 R08: 0000000000000000 R09: 0000000000000318 R10: 00000000f0000000 R11: 0000000000000001 R12: ffffffff880fabf0 R13: dead000000000122 R14: dead000000000100 R15: ffff99d63a154d80 FS: 00007ff3dbd5b740(0000) GS:ffff99d6560c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001cb5de6a9000 CR3: 000000016eb6a004 CR4: 00000000001606e0 Call Trace: __nf_tables_abort+0x3e3/0x6d0 [nf_tables] nft_request_module+0x6f/0x110 [nf_tables] nft_expr_type_request_module+0x28/0x50 [nf_tables] nf_tables_expr_parse+0x198/0x1f0 [nf_tables] nft_expr_init+0x3b/0xf0 [nf_tables] nft_dynset_init+0x1e2/0x410 [nf_tables] nf_tables_newrule+0x30a/0x930 [nf_tables] nfnetlink_rcv_batch+0x2a0/0x640 [nfnetlink] nfnetlink_rcv+0x125/0x171 [nfnetlink] netlink_unicast+0x179/0x210 netlink_sendmsg+0x208/0x3d0 sock_sendmsg+0x5e/0x60 ____sys_sendmsg+0x21b/0x290 Update comment on the code to describe the new behaviour. Reported-by: Marco Oliverio <[email protected]> Fixes: 452238e8d5ff ("netfilter: nf_tables: add and use helper for module autoload") Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-01-16Merge tag 'asoc-fix-v5.5-rc6' of ↵Takashi Iwai12-80/+209
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.5 This is mostly driver specific fixes, plus an error handling fix in the core. There is a rather large diffstat for the stm32 SAI driver, this is a very large but mostly mechanical update which wraps every register access in the driver to allow a fix to the locking which avoids circular locks, the active change is much smaller and more reasonably sized.
2020-01-16net: dsa: tag_qca: fix doubled Tx statisticsAlexander Lobakin1-3/+0
DSA subsystem takes care of netdev statistics since commit 4ed70ce9f01c ("net: dsa: Refactor transmit path to eliminate duplication"), so any accounting inside tagger callbacks is redundant and can lead to messing up the stats. This bug is present in Qualcomm tagger since day 0. Fixes: cafdc45c949b ("net-next: dsa: add Qualcomm tag RX/TX handler") Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-16net: dsa: tag_gswip: fix typo in tagger nameAlexander Lobakin1-1/+1
The correct name is GSWIP (Gigabit Switch IP). Typo was introduced in 875138f81d71a ("dsa: Move tagger name into its ops structure") while moving tagger names to their structures. Fixes: 875138f81d71a ("dsa: Move tagger name into its ops structure") Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Acked-by: Hauke Mehrtens <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-16net: ethernet: ave: Avoid lockdep warningKunihiko Hayashi1-7/+13
When building with PROVE_LOCKING=y, lockdep shows the following dump message. INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. ... Calling device_set_wakeup_enable() directly occurs this issue, and it isn't necessary for initialization, so this patch creates internal function __ave_ethtool_set_wol() and replaces with this in ave_init() and ave_resume(). Fixes: 7200f2e3c9e2 ("net: ethernet: ave: Set initial wol state to disabled") Signed-off-by: Kunihiko Hayashi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-16net: hns3: pad the short frame before sending to the hardwareYunsheng Lin1-0/+6
The hardware can not handle short frames below or equal to 32 bytes according to the hardware user manual, and it will trigger a RAS error when the frame's length is below 33 bytes. This patch pads the SKB when skb->len is below 33 bytes before sending it to hardware. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Yunsheng Lin <[email protected]> Signed-off-by: Huazhong Tan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-16macvlan: use skb_reset_mac_header() in macvlan_queue_xmit()Eric Dumazet1-2/+3
I missed the fact that macvlan_broadcast() can be used both in RX and TX. skb_eth_hdr() makes only sense in TX paths, so we can not use it blindly in macvlan_broadcast() Fixes: 96cc4b69581d ("macvlan: do not assume mac_header is set in macvlan_broadcast()") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: Jurgen Van Ham <[email protected]> Tested-by: Matteo Croce <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-16fuse: fix fuse_send_readpages() in the syncronous read caseMiklos Szeredi1-1/+3
Buffered read in fuse normally goes via: -> generic_file_buffered_read() -> fuse_readpages() -> fuse_send_readpages() ->fuse_simple_request() [called since v5.4] In the case of a read request, fuse_simple_request() will return a non-negative bytecount on success or a negative error value. A positive bytecount was taken to be an error and the PG_error flag set on the page. This resulted in generic_file_buffered_read() falling back to ->readpage(), which would repeat the read request and succeed. Because of the repeated read succeeding the bug was not detected with regression tests or other use cases. The FTP module in GVFS however fails the second read due to the non-seekable nature of FTP downloads. Fix by checking and ignoring positive return value from fuse_simple_request(). Reported-by: Ondrej Holy <[email protected]> Link: https://gitlab.gnome.org/GNOME/gvfs/issues/441 Fixes: 134831e36bbd ("fuse: convert readpages to simple api") Cc: <[email protected]> # v5.4 Signed-off-by: Miklos Szeredi <[email protected]>
2020-01-16Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller13-43/+95
Daniel Borkmann says: ==================== pull-request: bpf 2020-01-15 The following pull-request contains BPF updates for your *net* tree. We've added 12 non-merge commits during the last 9 day(s) which contain a total of 13 files changed, 95 insertions(+), 43 deletions(-). The main changes are: 1) Fix refcount leak for TCP time wait and request sockets for socket lookup related BPF helpers, from Lorenz Bauer. 2) Fix wrong verification of ARSH instruction under ALU32, from Daniel Borkmann. 3) Batch of several sockmap and related TLS fixes found while operating more complex BPF programs with Cilium and OpenSSL, from John Fastabend. 4) Fix sockmap to read psock's ingress_msg queue before regular sk_receive_queue() to avoid purging data upon teardown, from Lingpeng Chen. 5) Fix printing incorrect pointer in bpftool's btf_dump_ptr() in order to properly dump a BPF map's value with BTF, from Martin KaFai Lau. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-01-15io_uring: ensure workqueue offload grabs ring mutex for poll listJens Axboe1-0/+9
A previous commit moved the locking for the async sqthread, but didn't take into account that the io-wq workers still need it. We can't use req->in_async for this anymore as both the sqthread and io-wq workers set it, gate the need for locking on io_wq_current_is_worker() instead. Fixes: 8a4955ff1cca ("io_uring: sqthread should grab ctx->uring_lock for submissions") Reported-by: Bijan Mottahedeh <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-01-15block: fix an integer overflow in logical block sizeMikulas Patocka4-7/+7
Logical block size has type unsigned short. That means that it can be at most 32768. However, there are architectures that can run with 64k pages (for example arm64) and on these architectures, it may be possible to create block devices with 64k block size. For exmaple (run this on an architecture with 64k pages): Mount will fail with this error because it tries to read the superblock using 2-sector access: device-mapper: writecache: I/O is not aligned, sector 2, size 1024, block size 65536 EXT4-fs (dm-0): unable to read superblock This patch changes the logical block size from unsigned short to unsigned int to avoid the overflow. Cc: [email protected] Reviewed-by: Martin K. Petersen <[email protected]> Reviewed-by: Ming Lei <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-01-15io_uring: clear req->result always before issuing a read/write requestBijan Mottahedeh1-0/+2
req->result is cleared when io_issue_sqe() calls io_read/write_pre() routines. Those routines however are not called when the sqe argument is NULL, which is the case when io_issue_sqe() is called from io_wq_submit_work(). io_issue_sqe() may then examine a stale result if a polled request had previously failed with -EAGAIN: if (ctx->flags & IORING_SETUP_IOPOLL) { if (req->result == -EAGAIN) return -EAGAIN; io_iopoll_req_issued(req); } and in turn cause a subsequently completed request to be re-issued in io_wq_submit_work(). Signed-off-by: Bijan Mottahedeh <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-01-15scsi: mptfusion: Fix double fetch bug in ioctlDan Carpenter1-163/+50
Tom Hatskevich reported that we look up "iocp" then, in the called functions we do a second copy_from_user() and look it up again. The problem that could cause is: drivers/message/fusion/mptctl.c 674 /* All of these commands require an interrupt or 675 * are unknown/illegal. 676 */ 677 if ((ret = mptctl_syscall_down(iocp, nonblock)) != 0) ^^^^ We take this lock. 678 return ret; 679 680 if (cmd == MPTFWDOWNLOAD) 681 ret = mptctl_fw_download(arg); ^^^ Then the user memory changes and we look up "iocp" again but a different one so now we are holding the incorrect lock and have a race condition. 682 else if (cmd == MPTCOMMAND) 683 ret = mptctl_mpt_command(arg); The security impact of this bug is not as bad as it could have been because these operations are all privileged and root already has enormous destructive power. But it's still worth fixing. This patch passes the "iocp" pointer to the functions to avoid the second lookup. That deletes 100 lines of code from the driver so it's a nice clean up as well. Link: https://lore.kernel.org/r/20200114123414.GA7957@kadam Reported-by: Tom Hatskevich <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-01-15scsi: storvsc: Correctly set number of hardware queues for IDE diskLong Li1-1/+3
Commit 0ed881027690 ("scsi: storvsc: setup 1:1 mapping between hardware queue and CPU queue") introduced a regression for disks attached to IDE. For these disks the host VSP only offers one VMBUS channel. Setting multiple queues can overload the VMBUS channel and result in performance drop for high queue depth workload on system with large number of CPUs. Fix it by leaving the number of hardware queues to 1 (default value) for IDE disks. Fixes: 0ed881027690 ("scsi: storvsc: setup 1:1 mapping between hardware queue and CPU queue") Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ming Lei <[email protected]> Signed-off-by: Long Li <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-01-15scsi: fnic: fix invalid stack accessArnd Bergmann1-10/+10
gcc -O3 warns that some local variables are not properly initialized: drivers/scsi/fnic/vnic_dev.c: In function 'fnic_dev_hang_notify': drivers/scsi/fnic/vnic_dev.c:511:16: error: 'a0' is used uninitialized in this function [-Werror=uninitialized] vdev->args[0] = *a0; ~~~~~~~~~~~~~~^~~~~ drivers/scsi/fnic/vnic_dev.c:691:6: note: 'a0' was declared here u64 a0, a1; ^~ drivers/scsi/fnic/vnic_dev.c:512:16: error: 'a1' is used uninitialized in this function [-Werror=uninitialized] vdev->args[1] = *a1; ~~~~~~~~~~~~~~^~~~~ drivers/scsi/fnic/vnic_dev.c:691:10: note: 'a1' was declared here u64 a0, a1; ^~ drivers/scsi/fnic/vnic_dev.c: In function 'fnic_dev_mac_addr': drivers/scsi/fnic/vnic_dev.c:512:16: error: 'a1' is used uninitialized in this function [-Werror=uninitialized] vdev->args[1] = *a1; ~~~~~~~~~~~~~~^~~~~ drivers/scsi/fnic/vnic_dev.c:698:10: note: 'a1' was declared here u64 a0, a1; ^~ Apparently the code relies on the local variables occupying adjacent memory locations in the same order, but this is of course not guaranteed. Use an array of two u64 variables where needed to make it work correctly. I suspect there is also an endianness bug here, but have not digged in deep enough to be sure. Fixes: 5df6d737dd4b ("[SCSI] fnic: Add new Cisco PCI-Express FCoE HBA") Fixes: mmtom ("init/Kconfig: enable -O3 for all arches") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-01-15riscv: make sure the cores stay looping in .Lsecondary_parkGreentime Hu1-6/+10
The code in secondary_park is currently placed in the .init section. The kernel reclaims and clears this code when it finishes booting. That causes the cores parked in it to go to somewhere unpredictable, so we move this function out of init to make sure the cores stay looping there. The instruction bgeu a0, t0, .Lsecondary_park may have "a relocation truncated to fit" issue during linking time. It is because that sections are too far to jump. Let's use tail to jump to the .Lsecondary_park. Signed-off-by: Greentime Hu <[email protected]> Reviewed-by: Anup Patel <[email protected]> Cc: Andreas Schwab <[email protected]> Cc: [email protected] Fixes: 76d2a0493a17d ("RISC-V: Init and Halt Code") Signed-off-by: Paul Walmsley <[email protected]>
2020-01-16Merge tag 'amd-drm-fixes-5.5-2020-01-15' of ↵Dave Airlie2-2/+2
git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.5-2020-01-15: - Update golden settings for renoir - eDP fix Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-15drm/amd/display: Reorder detect_edp_sink_caps before link settings read.Mario Kleiner1-1/+1
read_current_link_settings_on_detect() on eDP 1.4+ may use the edp_supported_link_rates table which is set up by detect_edp_sink_caps(), so that function needs to be called first. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Mario Kleiner <[email protected]> Cc: Martin Leung <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-01-15drm/amdgpu: update goldensetting for renoirAaron Liu1-1/+1
Update mmSDMA0_UTCL1_WATERMK golden setting for renoir. Signed-off-by: Aaron Liu <[email protected]> Reviewed-by: Huang Rui <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-01-15Merge branch 'bpf-sockmap-tls-fixes'Daniel Borkmann9-25/+66
John Fastabend says: ==================== To date our usage of sockmap/tls has been fairly simple, the BPF programs did only well-defined pop, push, pull and apply/cork operations. Now that we started to push more complex programs into sockmap we uncovered a series of issues addressed here. Further OpenSSL3.0 version should be released soon with kTLS support so its important to get any remaining issues on BPF and kTLS support resolved. Additionally, I have a patch under development to allow sockmap to be enabled/disabled at runtime for Cilium endpoints. This allows us to stress the map insert/delete with kTLS more than previously where Cilium only added the socket to the map when it entered ESTABLISHED state and never touched it from the control path side again relying on the sockets own close() hook to remove it. To test I have a set of test cases in test_sockmap.c that expose these issues. Once we get fixes here merged and in bpf-next I'll submit the tests to bpf-next tree to ensure we don't regress again. Also I've run these patches in the Cilium CI with OpenSSL (master branch) this will run tools such as netperf, ab, wrk2, curl, etc. to get a broad set of testing. I'm aware of two more issues that we are working to resolve in another couple (probably two) patches. First we see an auth tag corruption in kTLS when sending small 1byte chunks under stress. I've not pinned this down yet. But, guessing because its under 1B stress tests it must be some error path being triggered. And second we need to ensure BPF RX programs are not skipped when kTLS ULP is loaded. This breaks some of the sockmap selftests when running with kTLS. I'll send a follow up for this. v2: I dropped a patch that added !0 size check in tls_push_record this originated from a panic I caught awhile ago with a trace in the crypto stack. But I can not reproduce it anymore so will dig into that and send another patch later if needed. Anyways after a bit of thought it would be nicer if tls/crypto/bpf didn't require special case handling for the !0 size. ==================== Signed-off-by: Daniel Borkmann <[email protected]>
2020-01-15bpf: Sockmap/tls, fix pop data with SK_DROP return codeJohn Fastabend2-8/+2
When user returns SK_DROP we need to reset the number of copied bytes to indicate to the user the bytes were dropped and not sent. If we don't reset the copied arg sendmsg will return as if those bytes were copied giving the user a positive return value. This works as expected today except in the case where the user also pops bytes. In the pop case the sg.size is reduced but we don't correctly account for this when copied bytes is reset. The popped bytes are not accounted for and we return a small positive value potentially confusing the user. The reason this happens is due to a typo where we do the wrong comparison when accounting for pop bytes. In this fix notice the if/else is not needed and that we have a similar problem if we push data except its not visible to the user because if delta is larger the sg.size we return a negative value so it appears as an error regardless. Fixes: 7246d8ed4dcce ("bpf: helper to pop data from messages") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jonathan Lemon <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/bpf/[email protected]
2020-01-15bpf: Sockmap/tls, skmsg can have wrapped skmsg that needs extra chainingJohn Fastabend1-0/+6
Its possible through a set of push, pop, apply helper calls to construct a skmsg, which is just a ring of scatterlist elements, with the start value larger than the end value. For example, end start |_0_|_1_| ... |_n_|_n+1_| Where end points at 1 and start points and n so that valid elements is the set {n, n+1, 0, 1}. Currently, because we don't build the correct chain only {n, n+1} will be sent. This adds a check and sg_chain call to correctly submit the above to the crypto and tls send path. Fixes: d3b18ad31f93d ("tls: add bpf support to sk_msg handling") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jonathan Lemon <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/bpf/[email protected]
2020-01-15bpf: Sockmap/tls, tls_sw can create a plaintext buf > encrypt bufJohn Fastabend1-0/+20
It is possible to build a plaintext buffer using push helper that is larger than the allocated encrypt buffer. When this record is pushed to crypto layers this can result in a NULL pointer dereference because the crypto API expects the encrypt buffer is large enough to fit the plaintext buffer. Kernel splat below. To resolve catch the cases this can happen and split the buffer into two records to send individually. Unfortunately, there is still one case to handle where the split creates a zero sized buffer. In this case we merge the buffers and unmark the split. This happens when apply is zero and user pushed data beyond encrypt buffer. This fixes the original case as well because the split allocated an encrypt buffer larger than the plaintext buffer and the merge simply moves the pointers around so we now have a reference to the new (larger) encrypt buffer. Perhaps its not ideal but it seems the best solution for a fixes branch and avoids handling these two cases, (a) apply that needs split and (b) non apply case. The are edge cases anyways so optimizing them seems not necessary unless someone wants later in next branches. [ 306.719107] BUG: kernel NULL pointer dereference, address: 0000000000000008 [...] [ 306.747260] RIP: 0010:scatterwalk_copychunks+0x12f/0x1b0 [...] [ 306.770350] Call Trace: [ 306.770956] scatterwalk_map_and_copy+0x6c/0x80 [ 306.772026] gcm_enc_copy_hash+0x4b/0x50 [ 306.772925] gcm_hash_crypt_remain_continue+0xef/0x110 [ 306.774138] gcm_hash_crypt_continue+0xa1/0xb0 [ 306.775103] ? gcm_hash_crypt_continue+0xa1/0xb0 [ 306.776103] gcm_hash_assoc_remain_continue+0x94/0xa0 [ 306.777170] gcm_hash_assoc_continue+0x9d/0xb0 [ 306.778239] gcm_hash_init_continue+0x8f/0xa0 [ 306.779121] gcm_hash+0x73/0x80 [ 306.779762] gcm_encrypt_continue+0x6d/0x80 [ 306.780582] crypto_gcm_encrypt+0xcb/0xe0 [ 306.781474] crypto_aead_encrypt+0x1f/0x30 [ 306.782353] tls_push_record+0x3b9/0xb20 [tls] [ 306.783314] ? sk_psock_msg_verdict+0x199/0x300 [ 306.784287] bpf_exec_tx_verdict+0x3f2/0x680 [tls] [ 306.785357] tls_sw_sendmsg+0x4a3/0x6a0 [tls] test_sockmap test signature to trigger bug, [TEST]: (1, 1, 1, sendmsg, pass,redir,start 1,end 2,pop (1,2),ktls,): Fixes: d3b18ad31f93d ("tls: add bpf support to sk_msg handling") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jonathan Lemon <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/bpf/[email protected]
2020-01-15bpf: Sockmap/tls, msg_push_data may leave end mark in placeJohn Fastabend1-0/+1
Leaving an incorrect end mark in place when passing to crypto layer will cause crypto layer to stop processing data before all data is encrypted. To fix clear the end mark on push data instead of expecting users of the helper to clear the mark value after the fact. This happens when we push data into the middle of a skmsg and have room for it so we don't do a set of copies that already clear the end flag. Fixes: 6fff607e2f14b ("bpf: sk_msg program helper bpf_msg_push_data") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Song Liu <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/bpf/[email protected]
2020-01-15bpf: Sockmap, skmsg helper overestimates push, pull, and pop boundsJohn Fastabend1-5/+5
In the push, pull, and pop helpers operating on skmsg objects to make data writable or insert/remove data we use this bounds check to ensure specified data is valid, /* Bounds checks: start and pop must be inside message */ if (start >= offset + l || last >= msg->sg.size) return -EINVAL; The problem here is offset has already included the length of the current element the 'l' above. So start could be past the end of the scatterlist element in the case where start also points into an offset on the last skmsg element. To fix do the accounting slightly different by adding the length of the previous entry to offset at the start of the iteration. And ensure its initialized to zero so that the first iteration does nothing. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Fixes: 6fff607e2f14b ("bpf: sk_msg program helper bpf_msg_push_data") Fixes: 7246d8ed4dcce ("bpf: helper to pop data from messages") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Song Liu <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/bpf/[email protected]
2020-01-15bpf: Sockmap/tls, push write_space updates through ulp updatesJohn Fastabend4-11/+23
When sockmap sock with TLS enabled is removed we cleanup bpf/psock state and call tcp_update_ulp() to push updates to TLS ULP on top. However, we don't push the write_space callback up and instead simply overwrite the op with the psock stored previous op. This may or may not be correct so to ensure we don't overwrite the TLS write space hook pass this field to the ULP and have it fixup the ctx. This completes a previous fix that pushed the ops through to the ULP but at the time missed doing this for write_space, presumably because write_space TLS hook was added around the same time. Fixes: 95fa145479fbc ("bpf: sockmap/tls, close can race with map free") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Jakub Sitnicki <[email protected]> Acked-by: Jonathan Lemon <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/bpf/[email protected]
2020-01-15bpf: Sockmap, ensure sock lock held during tear downJohn Fastabend2-1/+8
The sock_map_free() and sock_hash_free() paths used to delete sockmap and sockhash maps walk the maps and destroy psock and bpf state associated with the socks in the map. When done the socks no longer have BPF programs attached and will function normally. This can happen while the socks in the map are still "live" meaning data may be sent/received during the walk. Currently, though we don't take the sock_lock when the psock and bpf state is removed through this path. Specifically, this means we can be writing into the ops structure pointers such as sendmsg, sendpage, recvmsg, etc. while they are also being called from the networking side. This is not safe, we never used proper READ_ONCE/WRITE_ONCE semantics here if we believed it was safe. Further its not clear to me its even a good idea to try and do this on "live" sockets while networking side might also be using the socket. Instead of trying to reason about using the socks from both sides lets realize that every use case I'm aware of rarely deletes maps, in fact kubernetes/Cilium case builds map at init and never tears it down except on errors. So lets do the simple fix and grab sock lock. This patch wraps sock deletes from maps in sock lock and adds some annotations so we catch any other cases easier. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Song Liu <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/bpf/[email protected]
2020-01-15bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loopJohn Fastabend1-0/+1
When a sockmap is free'd and a socket in the map is enabled with tls we tear down the bpf context on the socket, the psock struct and state, and then call tcp_update_ulp(). The tcp_update_ulp() call is to inform the tls stack it needs to update its saved sock ops so that when the tls socket is later destroyed it doesn't try to call the now destroyed psock hooks. This is about keeping stacked ULPs in good shape so they always have the right set of stacked ops. However, recently unhash() hook was removed from TLS side. But, the sockmap/bpf side is not doing any extra work to update the unhash op when is torn down instead expecting TLS side to manage it. So both TLS and sockmap believe the other side is managing the op and instead no one updates the hook so it continues to point at tcp_bpf_unhash(). When unhash hook is called we call tcp_bpf_unhash() which detects the psock has already been destroyed and calls sk->sk_prot_unhash() which calls tcp_bpf_unhash() yet again and so on looping and hanging the core. To fix have sockmap tear down logic fixup the stale pointer. Fixes: 5d92e631b8be ("net/tls: partially revert fix transition through disconnect with close") Reported-by: [email protected] Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Jakub Sitnicki <[email protected]> Acked-by: Song Liu <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/bpf/[email protected]
2020-01-15Merge branch 'stmmac-Fix-selftests-in-Synopsys-AXS101-board'David S. Miller1-10/+22
Jose Abreu says: ==================== net: stmmac: Fix selftests in Synopsys AXS101 board Set of fixes for sefltests so that they work in Synopsys AXS101 board. Final output: $ ethtool -t eth0 The test result is PASS The test extra info: 1. MAC Loopback 0 2. PHY Loopback -95 3. MMC Counters 0 4. EEE -95 5. Hash Filter MC 0 6. Perfect Filter UC 0 7. MC Filter 0 8. UC Filter 0 9. Flow Control -95 10. RSS -95 11. VLAN Filtering -95 12. VLAN Filtering (perf) -95 13. Double VLAN Filter -95 14. Double VLAN Filter (perf) -95 15. Flexible RX Parser -95 16. SA Insertion (desc) -95 17. SA Replacement (desc) -95 18. SA Insertion (reg) -95 19. SA Replacement (reg) -95 20. VLAN TX Insertion -95 21. SVLAN TX Insertion -95 22. L3 DA Filtering -95 23. L3 SA Filtering -95 24. L4 DA TCP Filtering -95 25. L4 SA TCP Filtering -95 26. L4 DA UDP Filtering -95 27. L4 SA UDP Filtering -95 28. ARP Offload -95 29. Jumbo Frame 0 30. Multichannel Jumbo -95 31. Split Header -95 Description: 1) Fixes the unaligned accesses that caused CPU halt in Synopsys AXS101 boards. 2) Fixes the VLAN tests when filtering failed to work. 3) Fixes the VLAN Perfect tests when filtering is not available in HW. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-01-15net: stmmac: selftests: Guard VLAN Perfect test against non supported HWJose Abreu1-0/+6
When HW does not support perfect filtering the feature will not be enabled in the net_device. Add a check for this to prevent failures. Fixes: 1b2250a04c1f ("net: stmmac: selftests: Add tests for VLAN Perfect Filtering") Signed-off-by: Jose Abreu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-15net: stmmac: selftests: Mark as fail when received VLAN ID != expectedJose Abreu1-1/+5
When the VLAN ID does not match the expected one it means filter failed in HW. Fix it. Fixes: 94e18382003c ("net: stmmac: selftests: Add selftest for VLAN TX Offload") Signed-off-by: Jose Abreu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.