aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-11-12vrf: Fix fast path output packet handling with async Netfilter rulesMartin Willi1-23/+69
VRF devices use an optimized direct path on output if a default qdisc is involved, calling Netfilter hooks directly. This path, however, does not consider Netfilter rules completing asynchronously, such as with NFQUEUE. The Netfilter okfn() is called for asynchronously accepted packets, but the VRF never passes that packet down the stack to send it out over the slave device. Using the slower redirect path for this seems not feasible, as we do not know beforehand if a Netfilter hook has asynchronously completing rules. Fix the use of asynchronously completing Netfilter rules in OUTPUT and POSTROUTING by using a special completion function that additionally calls dst_output() to pass the packet down the stack. Also, slightly adjust the use of nf_reset_ct() so that is called in the asynchronous case, too. Fixes: dcdd43c41e60 ("net: vrf: performance improvements for IPv4") Fixes: a9ec54d1b0cd ("net: vrf: performance improvements for IPv6") Signed-off-by: Martin Willi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-12NFS: Remove unnecessary inode lock in nfs_fsync_dir()Trond Myklebust1-5/+1
nfs_inc_stats() is already thread-safe, and there are no other reasons to hold the inode lock here. Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2020-11-12NFS: Remove unnecessary inode locking in nfs_llseek_dir()Trond Myklebust1-5/+4
Remove the contentious inode lock, and instead provide thread safety using the file->f_lock spinlock. Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2020-11-12NFS: Fix listxattr receive buffer sizeChuck Lever1-2/+2
Certain NFSv4.2/RDMA tests fail with v5.9-rc1. rpcrdma_convert_kvec() runs off the end of the rl_segments array because rq_rcv_buf.tail[0].iov_len holds a very large positive value. The resultant kernel memory corruption is enough to crash the client system. Callers of rpc_prepare_reply_pages() must reserve an extra XDR_UNIT in the maximum decode size for a possible XDR pad of the contents of the xdr_buf's pages. That guarantees the allocated receive buffer will be large enough to accommodate the usual contents plus that XDR pad word. encode_op_hdr() cannot add that extra word. If it does, xdr_inline_pages() underruns the length of the tail iovec. Fixes: 3e1f02123fba ("NFSv4.2: add client side XDR handling for extended attributes") Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2020-11-12NFSv4.2: fix failure to unregister shrinkerJ. Bruce Fields1-0/+2
We forgot to unregister the nfs4_xattr_large_entry_shrinker. That leaves the global list of shrinkers corrupted after unload of the nfs module, after which possibly unrelated code that calls register_shrinker() or unregister_shrinker() gets a BUG() with "supervisor write access in kernel mode". And similarly for the nfs4_xattr_large_entry_lru. Reported-by: Kris Karas <[email protected]> Tested-By: Kris Karas <[email protected]> Fixes: 95ad37f90c33 "NFSv4.2: add client side xattr caching." Signed-off-by: J. Bruce Fields <[email protected]> CC: [email protected] Signed-off-by: Anna Schumaker <[email protected]>
2020-11-12Merge branches 'acpi-scan', 'acpi-misc', 'acpi-button' and 'acpi-dptf'Rafael J. Wysocki22-43/+64
* acpi-scan: ACPI: scan: Fix acpi_dma_configure_id() kerneldoc name * acpi-misc: ACPI: GED: fix -Wformat ACPI: Fix whitespace inconsistencies * acpi-button: ACPI: button: Add DMI quirk for Medion Akoya E2228T * acpi-dptf: ACPI: DPTF: Support Alder Lake
2020-11-12hwmon: (applesmc) Re-work SMC commsBrad Campbell1-48/+82
Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()") introduced an issue whereby communication with the SMC became unreliable with write errors like : [ 120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40 [ 120.378621] applesmc: LKSB: write data fail [ 120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40 [ 120.512787] applesmc: LKSB: write data fail The original code appeared to be timing sensitive and was not reliable with the timing changes in the aforementioned commit. This patch re-factors the SMC communication to remove the timing dependencies and restore function with the changes previously committed. Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2, MacBookAir1,1, MacBookAir3,1 Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()") Reported-by: Andreas Kemnade <[email protected]> Tested-by: Andreas Kemnade <[email protected]> # MacBookAir6,2 Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Brad Campbell <[email protected]> Signed-off-by: Henrik Rydberg <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-11-12hwmon: (pwm-fan) Fix RPM calculationPaul Barker1-7/+9
To convert the number of pulses counted into an RPM estimation, we need to divide by the width of our measurement interval instead of multiplying by it. If the width of the measurement interval is zero we don't update the RPM value to avoid dividing by zero. We also don't need to do 64-bit division, with 32-bits we can handle a fan running at over 4 million RPM. Signed-off-by: Paul Barker <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-11-12gfs2: fix possible reference leak in gfs2_check_blk_typeZhang Qilong1-5/+5
In the fail path of gfs2_check_blk_type, forgetting to call gfs2_glock_dq_uninit will result in rgd_gh reference leak. Signed-off-by: Zhang Qilong <[email protected]> Signed-off-by: Andreas Gruenbacher <[email protected]>
2020-11-11fscrypt: fix inline encryption not used on new filesEric Biggers1-1/+1
The new helper function fscrypt_prepare_new_inode() runs before S_ENCRYPTED has been set on the new inode. This accidentally made fscrypt_select_encryption_impl() never enable inline encryption on newly created files, due to its use of fscrypt_needs_contents_encryption() which only returns true when S_ENCRYPTED is set. Fix this by using S_ISREG() directly instead of fscrypt_needs_contents_encryption(), analogous to what select_encryption_mode() does. I didn't notice this earlier because by design, the user-visible behavior is the same (other than performance, potentially) regardless of whether inline encryption is used or not. Fixes: a992b20cd4ee ("fscrypt: add fscrypt_prepare_new_inode() and fscrypt_set_context()") Reviewed-by: Satya Tangirala <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]>
2020-11-11cosa: Add missing kfree in error path of cosa_writeWang Hai1-0/+1
If memory allocation for 'kbuf' succeed, cosa_write() doesn't have a corresponding kfree() in exception handling. Thus add kfree() for this function implementation. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wang Hai <[email protected]> Acked-by: Jan "Yenya" Kasprzak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11net: switch to the kernel.org patchwork instanceJakub Kicinski4-14/+14
Move to the kernel.org patchwork instance, it has significantly lower latency for accessing from Europe and the US. Other quirks include the reply bot. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11Merge branch 'cxgb4-ch_ktls-fixes-in-nic-tls-code'Jakub Kicinski7-228/+478
Rohit Maheshwari says: ==================== cxgb4/ch_ktls: Fixes in nic tls code This series helps in fixing multiple nic ktls issues. Series is broken into 12 patches. Patch 1 avoids deciding tls packet based on decrypted bit. If its a retransmit packet which has tls handshake and finish (for encryption), decrypted bit won't be set there, and so we can't rely on decrypted bit. Patch 2 helps supporting linear skb. SKBs were assumed non-linear. Corrected the length extraction. Patch 3 fixes the checksum offload update in WR. Patch 4 fixes kernel panic happening due to creating new skb for each record. As part of fix driver will use same skb to send out one tls record (partial data) of the same SKB. Patch 5 fixes the problem of skb data length smaller than remaining data of the record. Patch 6 fixes the handling of SKBs which has tls header alone pkt, but not starting from beginning. Patch 7 avoids sending extra data which is used to make a record 16 byte aligned. We don't need to retransmit those extra few bytes. Patch 8 handles the cases where retransmit packet has tls starting exchanges which are prior to tls start marker. Patch 9 fixes the problem os skb free before HW knows about tcp FIN. Patch 10 handles the small packet case which has partial TAG bytes only. HW can't handle those, hence using sw crypto for such pkts. Patch 11 corrects the potential tcb update problem. Patch 12 stops the queue if queue reaches threshold value. v1->v2: - Corrected fixes tag issue. - Marked chcr_ktls_sw_fallback() static. v2->v3: - Replaced GFP_KERNEL with GFP_ATOMIC. - Removed mixed fixes. v3->v4: - Corrected fixes tag issue. v4->v5: - Separated mixed fixes from patch 4. v5-v6: - Fixes tag should be at the end. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: stop the txq if reaches thresholdRohit Maheshwari1-3/+15
Stop the queue and ask for the credits if queue reaches to threashold. Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: tcb update fails sometimesRohit Maheshwari1-4/+8
context id and port id should be filled while sending tcb update. Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls/cxgb4: handle partial tag alone SKBsRohit Maheshwari4-1/+119
If TCP congestion caused a very small packets which only has some part fo the TAG, and that too is not till the end. HW can't handle such case, so falling back to sw crypto in such cases. v1->v2: - Marked chcr_ktls_sw_fallback() static. Fixes: dc05f3df8fac ("chcr: Handle first or middle part of record") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: don't free skb before sending FINRohit Maheshwari1-2/+10
If its a last packet and fin is set. Make sure FIN is informed to HW before skb gets freed. Fixes: 429765a149f1 ("chcr: handle partial end part of a record") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: packet handling prior to start markerRohit Maheshwari1-5/+33
There could be a case where ACK for tls exchanges prior to start marker is missed out, and by the time tls is offloaded. This pkt should not be discarded and handled carefully. It could be plaintext alone or plaintext + finish as well. Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: Correction in middle record handlingRohit Maheshwari1-19/+31
If a record starts in middle, reset TCB UNA so that we could avoid sending out extra packet which is needed to make it 16 byte aligned to start AES CTR. Check also considers prev_seq, which should be what is actually sent, not the skb data length. Avoid updating partial TAG to HW at any point of time, that's why we need to check if remaining part is smaller than TAG size, then reset TX_MAX to be TAG starting sequence number. Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: missing handling of header aloneRohit Maheshwari1-14/+11
If an skb has only header part which doesn't start from beginning, is not being handled properly. Fixes: dc05f3df8fac ("chcr: Handle first or middle part of record") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: Correction in trimmed_len calculationRohit Maheshwari1-4/+7
trimmed length calculation goes wrong if skb has only tag part to send. It should be zero if there is no data bytes apart from TAG. Fixes: dc05f3df8fac ("chcr: Handle first or middle part of record") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11cxgb4/ch_ktls: creating skbs causes panicRohit Maheshwari3-169/+226
Creating SKB per tls record and freeing the original one causes panic. There will be race if connection reset is requested. By freeing original skb, refcnt will be decremented and that means, there is no pending record to send, and so tls_dev_del will be requested in control path while SKB of related connection is in queue. Better approach is to use same SKB to send one record (partial data) at a time. We still have to create a new SKB when partial last part of a record is requested. This fix introduces new API cxgb4_write_partial_sgl() to send partial part of skb. Present cxgb4_write_sgl can only provide feasibility to start from an offset which limits to header only and it can write sgls for the whole skb len. But this new API will help in both. It can start from any offset and can end writing in middle of the skb. v4->v5: - Removed extra changes. Fixes: 429765a149f1 ("chcr: handle partial end part of a record") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: Update cheksum informationRohit Maheshwari1-4/+11
Checksum update was missing in the WR. Fixes: 429765a149f1 ("chcr: handle partial end part of a record") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11ch_ktls: Correction in finding correct lengthRohit Maheshwari1-7/+8
There is a possibility of linear skbs coming in. Correcting the length extraction logic. v2->v3: - Separated un-related changes from this patch. Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11cxgb4/ch_ktls: decrypted bit is not enoughRohit Maheshwari4-5/+8
If skb has retransmit data starting before start marker, e.g. ccs, decrypted bit won't be set for that, and if it has some data to encrypt, then it must be given to crypto ULD. So in place of decrypted, check if socket is tls offloaded. Also, unless skb has some data to encrypt, no need to give it for tls offload handling. v2->v3: - Removed ifdef. Fixes: 5a4b9fe7fece ("cxgb4/chcr: complete record tx handling") Signed-off-by: Rohit Maheshwari <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11dt-bindings: can: fsl,flexcan.yaml: fix fsl,stop-modeMarc Kleine-Budde1-5/+6
The fsl,stop-mode property is a phandle-array and should consist of one phandle and two 32 bit integers, e.g.: fsl,stop-mode = <&gpr 0x34 28>; This patch fixes the following errors, which shows up during a dtbs_check: arch/arm/boot/dts/imx6dl-apf6dev.dt.yaml: can@2090000: fsl,stop-mode: [[1, 52, 28]] is too short From schema: Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml Fixes: e5ab9aa7e49b ("dt-bindings: can: flexcan: convert fsl,*flexcan bindings to yaml") Reported-by: Rob Herring <[email protected]> Cc: Oleksij Rempel <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]>
2020-11-11of/address: Fix of_node memory leak in of_dma_is_coherentEvan Nimmo1-1/+3
Commit dabf6b36b83a ("of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc") added a check to of_dma_is_coherent which returns early if OF_DMA_DEFAULT_COHERENT is enabled. This results in the of_node_put() being skipped causing a memory leak. Moved the of_node_get() below this check so we now we only get the node if OF_DMA_DEFAULT_COHERENT is not enabled. Fixes: dabf6b36b83a ("of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc") Signed-off-by: Evan Nimmo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]>
2020-11-11net/x25: Fix null-ptr-deref in x25_connectMartin Schiller1-1/+1
This fixes a regression for blocking connects introduced by commit 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect"). The x25->neighbour is already set to "NULL" by x25_disconnect() now, while a blocking connect is waiting in x25_wait_for_connection_establishment(). Therefore x25->neighbour must not be accessed here again and x25->state is also already set to X25_STATE_0 by x25_disconnect(). Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect") Signed-off-by: Martin Schiller <[email protected]> Reviewed-by: Xie He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11arm64: dts: fsl-ls1028a-kontron-sl28: specify in-band mode for ENETCMichael Walle1-0/+1
Since commit 71b77a7a27a3 ("enetc: Migrate to PHYLINK and PCS_LYNX") the network port of the Kontron sl28 board is broken. After the migration to phylink the device tree has to specify the in-band-mode property. Add it. Fixes: 71b77a7a27a3 ("enetc: Migrate to PHYLINK and PCS_LYNX") Suggested-by: Vladimir Oltean <[email protected]> Signed-off-by: Michael Walle <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11tipc: fix memory leak in tipc_topsrv_start()Wang Hai1-2/+8
kmemleak report a memory leak as follows: unreferenced object 0xffff88810a596800 (size 512): comm "ip", pid 21558, jiffies 4297568990 (age 112.120s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 83 60 b0 ff ff ff ff ..........`..... backtrace: [<0000000022bbe21f>] tipc_topsrv_init_net+0x1f3/0xa70 [<00000000fe15ddf7>] ops_init+0xa8/0x3c0 [<00000000138af6f2>] setup_net+0x2de/0x7e0 [<000000008c6807a3>] copy_net_ns+0x27d/0x530 [<000000006b21adbd>] create_new_namespaces+0x382/0xa30 [<00000000bb169746>] unshare_nsproxy_namespaces+0xa1/0x1d0 [<00000000fe2e42bc>] ksys_unshare+0x39c/0x780 [<0000000009ba3b19>] __x64_sys_unshare+0x2d/0x40 [<00000000614ad866>] do_syscall_64+0x56/0xa0 [<00000000a1b5ca3c>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 'srv' is malloced in tipc_topsrv_start() but not free before leaving from the error handling cases. We need to free it. Fixes: 5c45ab24ac77 ("tipc: make struct tipc_server private for server.c") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wang Hai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-11Merge branch 'stable/for-linus-5.10-rc2' of ↵Linus Torvalds4-23/+17
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb Pull swiotlb fixes from Konrad Rzeszutek Wilk: "Two tiny fixes for issues that make drivers under Xen unhappy under certain conditions" * 'stable/for-linus-5.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb: swiotlb: remove the tbl_dma_addr argument to swiotlb_tbl_map_single swiotlb: fix "x86: Don't panic if can not alloc buffer for swiotlb"
2020-11-11Revert "ext4: fix superblock checksum calculation race"Theodore Ts'o1-11/+0
This reverts commit acaa532687cdc3a03757defafece9c27aa667546 which can result in a ext4_superblock_csum_set() trying to sleep while a spinlock is being held. For more discussion of this issue, please see: https://lore.kernel.org/r/[email protected] Reported-by: [email protected] Signed-off-by: Theodore Ts'o <[email protected]>
2020-11-11ext4: handle dax mount option collisionHarshad Shirwadkar1-3/+3
Mount options dax=inode and dax=never collided with fast_commit and journal checksum. Redefine the mount flags to remove the collision. Reported-by: Murphy Zhou <[email protected]> Fixes: 9cb20f94afcd2 ("fs/ext4: Make DAX mount option a tri-state") Signed-off-by: Harshad Shirwadkar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]>
2020-11-11io_uring: round-up cq size before comparing with rounded sq sizeJens Axboe1-1/+1
If an application specifies IORING_SETUP_CQSIZE to set the CQ ring size to a specific size, we ensure that the CQ size is at least that of the SQ ring size. But in doing so, we compare the already rounded up to power of two SQ size to the as-of yet unrounded CQ size. This means that if an application passes in non power of two sizes, we can return -EINVAL when the final value would've been fine. As an example, an application passing in 100/100 for sq/cq size should end up with 128 for both. But since we round the SQ size first, we compare the CQ size of 100 to 128, and return -EINVAL as that is too small. Cc: [email protected] Fixes: 33a107f0a1b8 ("io_uring: allow application controlled CQ ring size") Reported-by: Dan Melnic <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-11-11xfs: fix a missing unlock on error in xfs_fs_map_blocksChristoph Hellwig1-1/+1
We also need to drop the iolock when invalidate_inode_pages2 fails, not only on all other error or successful cases. Fixes: 527851124d10 ("xfs: implement pNFS export operations") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2020-11-11x86/platform/uv: Drop last traces of uv_flush_tlb_othersJiri Slaby1-10/+0
Commit 39297dde7390 ("x86/platform/uv: Remove UV BAU TLB Shootdown Handler") removed uv_flush_tlb_others. Its declaration was removed also from asm/uv/uv.h. But only for the CONFIG_X86_UV=y case. The inline definition (!X86_UV case) is still in place. So remove this implementation with everything what was added to support uv_flush_tlb_others: * include of asm/tlbflush.h * forward declarations of struct cpumask, mm_struct, and flush_tlb_info Signed-off-by: Jiri Slaby <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Mike Travis <[email protected]> Acked-by: Steve Wahl <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-11gpio: sifive: Fix SiFive gpio probeDamien Le Moal1-1/+1
Fix the check on the number of IRQs to allow up to the maximum (32) instead of only the maximum minus one. Fixes: 96868dce644d ("gpio/sifive: Add GPIO driver for SiFive SoCs") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-11-10scsi: ufshcd: Fix missing destroy_workqueue()Qinglang Miao1-0/+2
Add the missing destroy_workqueue() before return from ufshcd_init in the error handling case as well as in ufshcd_remove. Link: https://lore.kernel.org/r/[email protected] Fixes: 4db7a2360597 ("scsi: ufs: Fix concurrency of error handler and other error recovery paths") Suggested-by: Avri Altman <[email protected]> Reviewed-by: Asutosh Das <[email protected]> Reviewed-by: Avri Altman <[email protected]> Signed-off-by: Qinglang Miao <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-11-10Merge branch 'net-iucv-fixes-2020-11-09'Jakub Kicinski2-4/+2
Julian Wiedmann says: ==================== net/iucv: fixes 2020-11-09 One fix in the shutdown path for af_iucv sockets. This is relevant for stable as well. Also sending along an update for the Maintainers file. v1 -> v2: use the correct Fixes tag in patch 1 (Jakub) ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-10MAINTAINERS: remove Ursula Braun as s390 network maintainerUrsula Braun1-3/+0
I am retiring soon. Thus this patch removes myself from the MAINTAINERS file (s390 network). Signed-off-by: Ursula Braun <[email protected]> [jwi: fix up the subject] Signed-off-by: Julian Wiedmann <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-10net/af_iucv: fix null pointer dereference on shutdownUrsula Braun1-1/+2
syzbot reported the following KASAN finding: BUG: KASAN: nullptr-dereference in iucv_send_ctrl+0x390/0x3f0 net/iucv/af_iucv.c:385 Read of size 2 at addr 000000000000021e by task syz-executor907/519 CPU: 0 PID: 519 Comm: syz-executor907 Not tainted 5.9.0-syzkaller-07043-gbcf9877ad213 #0 Hardware name: IBM 3906 M04 701 (KVM/Linux) Call Trace: [<00000000c576af60>] unwind_start arch/s390/include/asm/unwind.h:65 [inline] [<00000000c576af60>] show_stack+0x180/0x228 arch/s390/kernel/dumpstack.c:135 [<00000000c9dcd1f8>] __dump_stack lib/dump_stack.c:77 [inline] [<00000000c9dcd1f8>] dump_stack+0x268/0x2f0 lib/dump_stack.c:118 [<00000000c5fed016>] print_address_description.constprop.0+0x5e/0x218 mm/kasan/report.c:383 [<00000000c5fec82a>] __kasan_report mm/kasan/report.c:517 [inline] [<00000000c5fec82a>] kasan_report+0x11a/0x168 mm/kasan/report.c:534 [<00000000c98b5b60>] iucv_send_ctrl+0x390/0x3f0 net/iucv/af_iucv.c:385 [<00000000c98b6262>] iucv_sock_shutdown+0x44a/0x4c0 net/iucv/af_iucv.c:1457 [<00000000c89d3a54>] __sys_shutdown+0x12c/0x1c8 net/socket.c:2204 [<00000000c89d3b70>] __do_sys_shutdown net/socket.c:2212 [inline] [<00000000c89d3b70>] __s390x_sys_shutdown+0x38/0x48 net/socket.c:2210 [<00000000c9e36eac>] system_call+0xe0/0x28c arch/s390/kernel/entry.S:415 There is nothing to shutdown if a connection has never been established. Besides that iucv->hs_dev is not yet initialized if a socket is in IUCV_OPEN state and iucv->path is not yet initialized if socket is in IUCV_BOUND state. So, just skip the shutdown calls for a socket in these states. Fixes: eac3731bd04c ("[S390]: Add AF_IUCV socket support") Fixes: 82492a355fac ("af_iucv: add shutdown for HS transport") Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Ursula Braun <[email protected]> [jwi: correct one Fixes tag] Signed-off-by: Julian Wiedmann <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-10lan743x: fix "BUG: invalid wait context" when setting rx modeSven Van Asbroeck2-12/+3
In the net core, the struct net_device_ops -> ndo_set_rx_mode() callback is called with the dev->addr_list_lock spinlock held. However, this driver's ndo_set_rx_mode callback eventually calls lan743x_dp_write(), which acquires a mutex. Mutex acquisition may sleep, and this is not allowed when holding a spinlock. Fix by removing the dp_lock mutex entirely. Its purpose is to prevent concurrent accesses to the data port. No concurrent accesses are possible, because the dev->addr_list_lock spinlock in the core only lets through one thread at a time. Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver") Signed-off-by: Sven Van Asbroeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-10net: dsa: mv88e6xxx: Fix memleak in mv88e6xxx_region_atu_snapshotzhangxiaoxu1-1/+3
When mv88e6xxx_fid_map return error, we lost free the table. Fix it. Fixes: bfb255428966 ("net: dsa: mv88e6xxx: Add devlink regions") Reported-by: Hulk Robot <[email protected]> Signed-off-by: zhangxiaoxu <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-10net: Update window_clamp if SOCK_RCVBUF is setMao Wenan2-4/+15
When net.ipv4.tcp_syncookies=1 and syn flood is happened, cookie_v4_check or cookie_v6_check tries to redo what tcp_v4_send_synack or tcp_v6_send_synack did, rsk_window_clamp will be changed if SOCK_RCVBUF is set, which will make rcv_wscale is different, the client still operates with initial window scale and can overshot granted window, the client use the initial scale but local server use new scale to advertise window value, and session work abnormally. Fixes: e88c64f0a425 ("tcp: allow effective reduction of TCP's rcv-buffer via setsockopt") Signed-off-by: Mao Wenan <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-11-10vfs: move __sb_{start,end}_write* to fs.hDarrick J. Wong2-33/+18
Now that we've straightened out the callers, move these three functions to fs.h since they're fairly trivial. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Jan Kara <[email protected]>
2020-11-10vfs: separate __sb_start_write into blocking and non-blocking helpersDarrick J. Wong4-19/+25
Break this function into two helpers so that it's obvious that the trylock versions return a value that must be checked, and the blocking versions don't require that. While we're at it, clean up the return type mismatch. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2020-11-10vfs: remove lockdep bogosity in __sb_start_writeDarrick J. Wong1-29/+4
__sb_start_write has some weird looking lockdep code that claims to exist to handle nested freeze locking requests from xfs. The code as written seems broken -- if we think we hold a read lock on any of the higher freeze levels (e.g. we hold SB_FREEZE_WRITE and are trying to lock SB_FREEZE_PAGEFAULT), it converts a blocking lock attempt into a trylock. However, it's not correct to downgrade a blocking lock attempt to a trylock unless the downgrading code or the callers are prepared to deal with that situation. Neither __sb_start_write nor its callers handle this at all. For example: sb_start_pagefault ignores the return value completely, with the result that if xfs_filemap_fault loses a race with a different thread trying to fsfreeze, it will proceed without pagefault freeze protection (thereby breaking locking rules) and then unlocks the pagefault freeze lock that it doesn't own on its way out (thereby corrupting the lock state), which leads to a system hang shortly afterwards. Normally, this won't happen because our ownership of a read lock on a higher freeze protection level blocks fsfreeze from grabbing a write lock on that higher level. *However*, if lockdep is offline, lock_is_held_type unconditionally returns 1, which means that percpu_rwsem_is_held returns 1, which means that __sb_start_write unconditionally converts blocking freeze lock attempts into trylocks, even when we *don't* hold anything that would block a fsfreeze. Apparently this all held together until 5.10-rc1, when bugs in lockdep caused lockdep to shut itself off early in an fstests run, and once fstests gets to the "race writes with freezer" tests, kaboom. This might explain the long trail of vanishingly infrequent livelocks in fstests after lockdep goes offline that I've never been able to diagnose. We could fix it by spinning on the trylock if wait==true, but AFAICT the locking works fine if lockdep is not built at all (and I didn't see any complaints running fstests overnight), so remove this snippet entirely. NOTE: Commit f4b554af9931 in 2015 created the current weird logic (which used to exist in a different form in commit 5accdf82ba25c from 2012) in __sb_start_write. XFS solved this whole problem in the late 2.6 era by creating a variant of transactions (XFS_TRANS_NO_WRITECOUNT) that don't grab intwrite freeze protection, thus making lockdep's solution unnecessary. The commit claims that Dave Chinner explained that the trylock hack + comment could be removed, but nobody ever did. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Jan Kara <[email protected]>
2020-11-10xfs: fix brainos in the refcount scrubber's rmap fragment processorDarrick J. Wong1-5/+3
Fix some serious WTF in the reference count scrubber's rmap fragment processing. The code comment says that this loop is supposed to move all fragment records starting at or before bno onto the worklist, but there's no obvious reason why nr (the number of items added) should increment starting from 1, and breaking the loop when we've added the target number seems dubious since we could have more rmap fragments that should have been added to the worklist. This seems to manifest in xfs/411 when adding one to the refcount field. Fixes: dbde19da9637 ("xfs: cross-reference the rmapbt data with the refcountbt") Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2020-11-10xfs: fix rmap key and record comparison functionsDarrick J. Wong1-8/+8
Keys for extent interval records in the reverse mapping btree are supposed to be computed as follows: (physical block, owner, fork, is_btree, is_unwritten, offset) This provides users the ability to look up a reverse mapping from a bmbt record -- start with the physical block; then if there are multiple records for the same block, move on to the owner; then the inode fork type; and so on to the file offset. However, the key comparison functions incorrectly remove the fork/btree/unwritten information that's encoded in the on-disk offset. This means that lookup comparisons are only done with: (physical block, owner, offset) This means that queries can return incorrect results. On consistent filesystems this hasn't been an issue because blocks are never shared between forks or with bmbt blocks; and are never unwritten. However, this bug means that online repair cannot always detect corruption in the key information in internal rmapbt nodes. Found by fuzzing keys[1].attrfork = ones on xfs/371. Fixes: 4b8ed67794fe ("xfs: add rmap btree operations") Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2020-11-10xfs: set the unwritten bit in rmap lookup flags in xchk_bmap_get_rmapextentsDarrick J. Wong1-0/+2
When the bmbt scrubber is looking up rmap extents, we need to set the extent flags from the bmbt record fully. This will matter once we fix the rmap btree comparison functions to check those flags correctly. Fixes: d852657ccfc0 ("xfs: cross-reference reverse-mapping btree") Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.