aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-02-13Merge branch '100GbE' of ↵David S. Miller18-675/+247
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2020-02-12 This series contains fixes to only the ice driver. Dave fixes logic flaws in the DCB rebuild function which is used after a reset. Also fixed a configuration issue when switching between firmware and software LLDP mode where the number of TLV's configured was getting out of sync with what lldpad thinks is configured. Paul fixes how the driver displayed all the supported and advertised link modes by basing it on the PHY capabilities, and in the process cleaned up a lot of code. Brett fixes duplicate receive tail bumps by comparing the value we are writing to tail with the previously written tail value. Also cleaned up workarounds that are no longer needed with the latest NVM images. Anirudh cleaned up unnecessary CONFIG_PCI_IOV wrappers. Updated the driver to use ice_pf_to_dev() instead of &pf->pdev->dev or &vsi->back->pdev->dev. Cleaned up the string format in print function calls to remove newlines where applicable. Akeem updates the link message logging to include "Full Duplex" and "Negotiated", to help distinguish from "Requested" for FEC. Bruce fixes and consolidates the logging of firmware/NVM information during driver load, since the information is duplicate of what is available via ethtool. Fixed the checking of the Unit Load Status bits after reset to ensure they are 0x7FF before continuing, by updating the mask. Cleanup up possible NULL dereferences that were created by a previous commit. Ben fixes the driver to use the correct netif_msg_tx/rx_error() to determine whether to print the MDD event type. Tony provides several trivial fixes, which include whitespace, typos, function header comments, reverse Christmas tree issues. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-02-13NFSv4: Ensure the delegation cred is pinned when we call delegreturnTrond Myklebust1-3/+8
Ensure we don't release the delegation cred during the call to nfs4_proc_delegreturn(). Fixes: ee05f456772d ("NFSv4: Fix races between open and delegreturn") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2020-02-13NFSv4: Ensure the delegation is pinned in nfs_do_return_delegation()Trond Myklebust2-7/+27
The call to nfs_do_return_delegation() needs to be taken without any RCU locks. Add a refcount to make sure the delegation remains pinned in memory until we're done. Fixes: ee05f456772d ("NFSv4: Fix races between open and delegreturn") Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2020-02-13NFSv4.1 make cachethis=no for writesOlga Kornievskaia1-1/+1
Turning caching off for writes on the server should improve performance. Fixes: fba83f34119a ("NFS: Pass "privileged" value to nfs4_init_sequence()") Signed-off-by: Olga Kornievskaia <[email protected]> Reviewed-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2020-02-13xprtrdma: Fix DMA scatter-gather list mapping imbalanceChuck Lever1-6/+7
The @nents value that was passed to ib_dma_map_sg() has to be passed to the matching ib_dma_unmap_sg() call. If ib_dma_map_sg() choses to concatenate sg entries, it will return a different nents value than it was passed. The bug was exposed by recent changes to the AMD IOMMU driver, which enabled sg entry concatenation. Looking all the way back to commit 4143f34e01e9 ("xprtrdma: Port to new memory registration API") and reviewing other kernel ULPs, it's not clear that the frwr_map() logic was ever correct for this case. Reported-by: Andre Tomt <[email protected]> Suggested-by: Robin Murphy <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Cc: [email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2020-02-13jbd2: do not clear the BH_Mapped flag when forgetting a metadata bufferzhangyi (F)1-4/+21
Commit 904cdbd41d74 ("jbd2: clear dirty flag when revoking a buffer from an older transaction") set the BH_Freed flag when forgetting a metadata buffer which belongs to the committing transaction, it indicate the committing process clear dirty bits when it is done with the buffer. But it also clear the BH_Mapped flag at the same time, which may trigger below NULL pointer oops when block_size < PAGE_SIZE. rmdir 1 kjournald2 mkdir 2 jbd2_journal_commit_transaction commit transaction N jbd2_journal_forget set_buffer_freed(bh1) jbd2_journal_commit_transaction commit transaction N+1 ... clear_buffer_mapped(bh1) ext4_getblk(bh2 ummapped) ... grow_dev_page init_page_buffers bh1->b_private=NULL bh2->b_private=NULL jbd2_journal_put_journal_head(jh1) __journal_remove_journal_head(hb1) jh1 is NULL and trigger oops *) Dir entry block bh1 and bh2 belongs to one page, and the bh2 has already been unmapped. For the metadata buffer we forgetting, we should always keep the mapped flag and clear the dirty flags is enough, so this patch pick out the these buffers and keep their BH_Mapped flag. Link: https://lore.kernel.org/r/[email protected] Fixes: 904cdbd41d74 ("jbd2: clear dirty flag when revoking a buffer from an older transaction") Reviewed-by: Jan Kara <[email protected]> Signed-off-by: zhangyi (F) <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected]
2020-02-13jbd2: move the clearing of b_modified flag to the journal_unmap_buffer()zhangyi (F)2-32/+21
There is no need to delay the clearing of b_modified flag to the transaction committing time when unmapping the journalled buffer, so just move it to the journal_unmap_buffer(). Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Jan Kara <[email protected]> Signed-off-by: zhangyi (F) <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected]
2020-02-13ext4: add cond_resched() to ext4_protect_reserved_inodeShijie Luo1-0/+1
When journal size is set too big by "mkfs.ext4 -J size=", or when we mount a crafted image to make journal inode->i_size too big, the loop, "while (i < num)", holds cpu too long. This could cause soft lockup. [ 529.357541] Call trace: [ 529.357551] dump_backtrace+0x0/0x198 [ 529.357555] show_stack+0x24/0x30 [ 529.357562] dump_stack+0xa4/0xcc [ 529.357568] watchdog_timer_fn+0x300/0x3e8 [ 529.357574] __hrtimer_run_queues+0x114/0x358 [ 529.357576] hrtimer_interrupt+0x104/0x2d8 [ 529.357580] arch_timer_handler_virt+0x38/0x58 [ 529.357584] handle_percpu_devid_irq+0x90/0x248 [ 529.357588] generic_handle_irq+0x34/0x50 [ 529.357590] __handle_domain_irq+0x68/0xc0 [ 529.357593] gic_handle_irq+0x6c/0x150 [ 529.357595] el1_irq+0xb8/0x140 [ 529.357599] __ll_sc_atomic_add_return_acquire+0x14/0x20 [ 529.357668] ext4_map_blocks+0x64/0x5c0 [ext4] [ 529.357693] ext4_setup_system_zone+0x330/0x458 [ext4] [ 529.357717] ext4_fill_super+0x2170/0x2ba8 [ext4] [ 529.357722] mount_bdev+0x1a8/0x1e8 [ 529.357746] ext4_mount+0x44/0x58 [ext4] [ 529.357748] mount_fs+0x50/0x170 [ 529.357752] vfs_kern_mount.part.9+0x54/0x188 [ 529.357755] do_mount+0x5ac/0xd78 [ 529.357758] ksys_mount+0x9c/0x118 [ 529.357760] __arm64_sys_mount+0x28/0x38 [ 529.357764] el0_svc_common+0x78/0x130 [ 529.357766] el0_svc_handler+0x38/0x78 [ 529.357769] el0_svc+0x8/0xc [ 541.356516] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [mount:18674] Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Shijie Luo <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected]
2020-02-13ext4: fix checksum errors with indexed dirsJan Kara4-7/+31
DIR_INDEX has been introduced as a compat ext4 feature. That means that even kernels / tools that don't understand the feature may modify the filesystem. This works because for kernels not understanding indexed dir format, internal htree nodes appear just as empty directory entries. Index dir aware kernels then check the htree structure is still consistent before using the data. This all worked reasonably well until metadata checksums were introduced. The problem is that these effectively made DIR_INDEX only ro-compatible because internal htree nodes store checksums in a different place than normal directory blocks. Thus any modification ignorant to DIR_INDEX (or just clearing EXT4_INDEX_FL from the inode) will effectively cause checksum mismatch and trigger kernel errors. So we have to be more careful when dealing with indexed directories on filesystems with checksumming enabled. 1) We just disallow loading any directory inodes with EXT4_INDEX_FL when DIR_INDEX is not enabled. This is harsh but it should be very rare (it means someone disabled DIR_INDEX on existing filesystem and didn't run e2fsck), e2fsck can fix the problem, and we don't want to answer the difficult question: "Should we rather corrupt the directory more or should we ignore that DIR_INDEX feature is not set?" 2) When we find out htree structure is corrupted (but the filesystem and the directory should in support htrees), we continue just ignoring htree information for reading but we refuse to add new entries to the directory to avoid corrupting it more. Link: https://lore.kernel.org/r/[email protected] Fixes: dbe89444042a ("ext4: Calculate and verify checksums for htree nodes") Reviewed-by: Andreas Dilger <[email protected]> Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected]
2020-02-13ext4: fix support for inode sizes > 1024 bytesTheodore Ts'o1-8/+10
A recent commit, 9803387c55f7 ("ext4: validate the debug_want_extra_isize mount option at parse time"), moved mount-time checks around. One of those changes moved the inode size check before the blocksize variable was set to the blocksize of the file system. After 9803387c55f7 was set to the minimum allowable blocksize, which in practice on most systems would be 1024 bytes. This cuased file systems with inode sizes larger than 1024 bytes to be rejected with a message: EXT4-fs (sdXX): unsupported inode size: 4096 Fixes: 9803387c55f7 ("ext4: validate the debug_want_extra_isize mount option at parse time") Link: https://lore.kernel.org/r/[email protected] Reported-by: Herbert Poetzl <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected]
2020-02-13crypto/testmgr: enable selftests for paes-s390 ciphersHarald Freudenberger1-0/+36
This patch enables the selftests for the s390 specific protected key AES (PAES) cipher implementations: * cbc-paes-s390 * ctr-paes-s390 * ecb-paes-s390 * xts-paes-s390 PAES is an AES cipher but with encrypted ('protected') key material. However, the paes ciphers are able to derive an protected key from clear key material with the help of the pkey kernel module. So this patch now enables the generic AES tests for the paes ciphers. Under the hood the setkey() functions rearrange the clear key values as clear key token and so the pkey kernel module is able to provide protected key blobs from the given clear key values. The derived protected key blobs are then used within the paes cipers and should produce the very same results as the generic AES implementation with the clear key values. The s390-paes cipher testlist entries are surrounded by #if IS_ENABLED(CONFIG_CRYPTO_PAES_S390) because they don't make any sense on non s390 platforms or without the PAES cipher implementation. Link: http://lkml.kernel.org/r/[email protected] Acked-by: Herbert Xu <[email protected]> Signed-off-by: Harald Freudenberger <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2020-02-13ext4: simplify checking quota limits in ext4_statfs()Jan Kara1-8/+2
Coverity reports that conditions checking quota limits in ext4_statfs() contain dead code. Indeed it is right and current conditions can be simplified. Link: https://lore.kernel.org/r/[email protected] Reported-by: Coverity <[email protected]> Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected]
2020-02-13ext4: don't assume that mmp_nodename/bdevname have NULAndreas Dilger1-5/+7
Don't assume that the mmp_nodename and mmp_bdevname strings are NUL terminated, since they are filled in by snprintf(), which is not guaranteed to do so. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Andreas Dilger <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected]
2020-02-13RDMA/core: Fix protection fault in get_pkey_idx_qp_listLeon Romanovsky1-15/+9
We don't need to set pkey as valid in case that user set only one of pkey index or port number, otherwise it will be resulted in NULL pointer dereference while accessing to uninitialized pkey list. The following crash from Syzkaller revealed it. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN PTI CPU: 1 PID: 14753 Comm: syz-executor.2 Not tainted 5.5.0-rc5 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 RIP: 0010:get_pkey_idx_qp_list+0x161/0x2d0 Code: 01 00 00 49 8b 5e 20 4c 39 e3 0f 84 b9 00 00 00 e8 e4 42 6e fe 48 8d 7b 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 01 0f 8e d0 00 00 00 48 8d 7d 04 48 b8 RSP: 0018:ffffc9000bc6f950 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff82c8bdec RDX: 0000000000000002 RSI: ffffc900030a8000 RDI: 0000000000000010 RBP: ffff888112c8ce80 R08: 0000000000000004 R09: fffff5200178df1f R10: 0000000000000001 R11: fffff5200178df1f R12: ffff888115dc4430 R13: ffff888115da8498 R14: ffff888115dc4410 R15: ffff888115da8000 FS: 00007f20777de700(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2f721000 CR3: 00000001173ca002 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: port_pkey_list_insert+0xd7/0x7c0 ib_security_modify_qp+0x6fa/0xfc0 _ib_modify_qp+0x8c4/0xbf0 modify_qp+0x10da/0x16d0 ib_uverbs_modify_qp+0x9a/0x100 ib_uverbs_write+0xaa5/0xdf0 __vfs_write+0x7c/0x100 vfs_write+0x168/0x4a0 ksys_write+0xc8/0x200 do_syscall_64+0x9c/0x390 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: d291f1a65232 ("IB/core: Enforce PKey security on QPs") Link: https://lore.kernel.org/r/20200212080651.GB679970@unreal Signed-off-by: Maor Gottlieb <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Message-Id: <20200212080651.GB679970@unreal>
2020-02-13bcache: remove macro nr_to_fifo_front()Coly Li1-5/+2
Macro nr_to_fifo_front() is only used once in btree_flush_write(), it is unncessary indeed. This patch removes this macro and does calculation directly in place. Signed-off-by: Coly Li <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-02-13bcache: Revert "bcache: shrink btree node cache after bch_btree_check()"Coly Li1-17/+0
This reverts commit 1df3877ff6a4810054237c3259d900ded4468969. In my testing, sometimes even all the cached btree nodes are freed, creating gc and allocator kernel threads may still fail. Finally it turns out that kthread_run() may fail if there is pending signal for current task. And the pending signal is sent from OOM killer which is triggered by memory consuption in bch_btree_check(). Therefore explicitly shrinking bcache btree node here does not help, and after the shrinker callback is improved, as well as pending signals are ignored before creating kernel threads, now such operation is unncessary anymore. This patch reverts the commit 1df3877ff6a4 ("bcache: shrink btree node cache after bch_btree_check()") because we have better improvement now. Signed-off-by: Coly Li <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-02-13bcache: ignore pending signals when creating gc and allocator threadColy Li2-2/+29
When run a cache set, all the bcache btree node of this cache set will be checked by bch_btree_check(). If the bcache btree is very large, iterating all the btree nodes will occupy too much system memory and the bcache registering process might be selected and killed by system OOM killer. kthread_run() will fail if current process has pending signal, therefore the kthread creating in run_cache_set() for gc and allocator kernel threads are very probably failed for a very large bcache btree. Indeed such OOM is safe and the registering process will exit after the registration done. Therefore this patch flushes pending signals during the cache set start up, specificly in bch_cache_allocator_start() and bch_gc_thread_start(), to make sure run_cache_set() won't fail for large cahced data set. Signed-off-by: Coly Li <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-02-13ALSA: pcm: Fix double hw_free callsTakashi Iwai1-1/+2
The commit 66f2d19f8116 ("ALSA: pcm: Fix memory leak at closing a stream without hw_free") tried to fix the regression wrt the missing hw_free call at closing without SNDRV_PCM_IOCTL_HW_FREE ioctl. However, the code change dropped mistakenly the state check, resulting in calling hw_free twice when SNDRV_PCM_IOCTL_HW_FRE got called beforehand. For most drivers, this is almost harmless, but the drivers like SOF show another regression now. This patch adds the state condition check before calling do_hw_free() at releasing the stream for avoiding the double hw_free calls. Fixes: 66f2d19f8116 ("ALSA: pcm: Fix memory leak at closing a stream without hw_free") Reported-by: Bard Liao <[email protected]> Reported-by: Pierre-Louis Bossart <[email protected]> Tested-by: Pierre-Louis Bossart <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-02-13RDMA/rxe: Fix soft lockup problem due to using tasklets in softirqZhu Yanjun1-4/+4
When run stress tests with RXE, the following Call Traces often occur watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [swapper/2:0] ... Call Trace: <IRQ> create_object+0x3f/0x3b0 kmem_cache_alloc_node_trace+0x129/0x2d0 __kmalloc_reserve.isra.52+0x2e/0x80 __alloc_skb+0x83/0x270 rxe_init_packet+0x99/0x150 [rdma_rxe] rxe_requester+0x34e/0x11a0 [rdma_rxe] rxe_do_task+0x85/0xf0 [rdma_rxe] tasklet_action_common.isra.21+0xeb/0x100 __do_softirq+0xd0/0x298 irq_exit+0xc5/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20 </IRQ> ... The root cause is that tasklet is actually a softirq. In a tasklet handler, another softirq handler is triggered. Usually these softirq handlers run on the same cpu core. So this will cause "soft lockup Bug". Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Zhu Yanjun <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-02-13RDMA/mlx5: Prevent overflow in mmap offset calculationsLeon Romanovsky1-2/+2
The cmd and index variables declared as u16 and the result is supposed to be stored in u64. The C arithmetic rules doesn't promote "(index >> 8) << 16" to be u64 and leaves the end result to be u16. Fixes: 7be76bef320b ("IB/mlx5: Introduce VAR object and its alloc/destroy methods") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-02-13IB/umad: Fix kernel crash while unloading ib_umadYonatan Cohen1-2/+3
When disassociating a device from umad we must ensure that the sysfs access is prevented before blocking the fops, otherwise assumptions in syfs don't hold: CPU0 CPU1 ib_umad_kill_port() ibdev_show() port->ib_dev = NULL dev_name(port->ib_dev) The prior patch made an error in moving the device_destroy(), it should have been split into device_del() (above) and put_device() (below). At this point we already have the split, so move the device_del() back to its original place. kernel stack PF: error_code(0x0000) - not-present page Oops: 0000 [#1] SMP DEBUG_PAGEALLOC PTI RIP: 0010:ibdev_show+0x18/0x50 [ib_umad] RSP: 0018:ffffc9000097fe40 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa0441120 RCX: ffff8881df514000 RDX: ffff8881df514000 RSI: ffffffffa0441120 RDI: ffff8881df1e8870 RBP: ffffffff81caf000 R08: ffff8881df1e8870 R09: 0000000000000000 R10: 0000000000001000 R11: 0000000000000003 R12: ffff88822f550b40 R13: 0000000000000001 R14: ffffc9000097ff08 R15: ffff8882238bad58 FS: 00007f1437ff3740(0000) GS:ffff888236940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000004e8 CR3: 00000001e0dfc001 CR4: 00000000001606e0 Call Trace: dev_attr_show+0x15/0x50 sysfs_kf_seq_show+0xb8/0x1a0 seq_read+0x12d/0x350 vfs_read+0x89/0x140 ksys_read+0x55/0xd0 do_syscall_64+0x55/0x1b0 entry_SYSCALL_64_after_hwframe+0x44/0xa9: Fixes: cf7ad3030271 ("IB/umad: Avoid destroying device while it is accessed") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Yonatan Cohen <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-02-13RDMA/mlx5: Fix async events cleanup flowsYishai Hadas1-23/+28
As in the prior patch, the devx code is not fully cleaning up its event_lists before finishing driver_destroy allowing a later read to trigger user after free conditions. Re-arrange things so that the event_list is always empty after destroy and ensure it remains empty until the file is closed. Fixes: f7c8416ccea5 ("RDMA/core: Simplify destruction of FD uobjects") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Yishai Hadas <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-02-13RDMA/core: Add missing list deletion on freeing event queueMichael Guralnik1-0/+1
When the uobject file scheme was revised to allow device disassociation from the file it became possible for read() to still happen the driver destroys the uobject. The old clode code was not tolerant to concurrent read, and when it was moved to the driver destroy it creates a bug. Ensure the event_list is empty after driver destroy by adding the missing list_del(). Otherwise read() can trigger a use after free and double kfree. Fixes: f7c8416ccea5 ("RDMA/core: Simplify destruction of FD uobjects") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michael Guralnik <[email protected]> Reviewed-by: Yishai Hadas <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-02-13EDAC/sysfs: Remove csrow objects on errorsRobert Richter1-2/+1
All created csrow objects must be removed in the error path of edac_create_csrow_objects(). The objects have been added as devices. They need to be removed by doing a device_del() *and* put_device() call to also free their memory. The missing put_device() leaves a memory leak. Use device_unregister() instead of device_del() which properly unregisters the device doing both. Fixes: 7adc05d2dc3a ("EDAC/sysfs: Drop device references properly") Signed-off-by: Robert Richter <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Tested-by: John Garry <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-02-13EDAC/mc: Fix use-after-free and memleaks during device removalRobert Richter2-21/+6
A test kernel with the options DEBUG_TEST_DRIVER_REMOVE, KASAN and DEBUG_KMEMLEAK set, revealed several issues when removing an mci device: 1) Use-after-free: On 27.11.19 17:07:33, John Garry wrote: > [ 22.104498] BUG: KASAN: use-after-free in > edac_remove_sysfs_mci_device+0x148/0x180 The use-after-free is caused by the mci_for_each_dimm() macro called in edac_remove_sysfs_mci_device(). The iterator was introduced with c498afaf7df8 ("EDAC: Introduce an mci_for_each_dimm() iterator"). The iterator loop calls device_unregister(&dimm->dev), which removes the sysfs entry of the device, but also frees the dimm struct in dimm_attr_release(). When incrementing the loop in mci_for_each_dimm(), the dimm struct is accessed again, after having been freed already. The fix is to free all the mci device's subsequent dimm and csrow objects at a later point, in _edac_mc_free(), when the mci device itself is being freed. This keeps the data structures intact and the mci device can be fully used until its removal. The change allows the safe usage of mci_for_each_dimm() to release dimm devices from sysfs. 2) Memory leaks: Following memory leaks have been detected: # grep edac /sys/kernel/debug/kmemleak | sort | uniq -c 1 [<000000003c0f58f9>] edac_mc_alloc+0x3bc/0x9d0 # mci->csrows 16 [<00000000bb932dc0>] edac_mc_alloc+0x49c/0x9d0 # csr->channels 16 [<00000000e2734dba>] edac_mc_alloc+0x518/0x9d0 # csr->channels[chn] 1 [<00000000eb040168>] edac_mc_alloc+0x5c8/0x9d0 # mci->dimms 34 [<00000000ef737c29>] ghes_edac_register+0x1c8/0x3f8 # see edac_mc_alloc() All leaks are from memory allocated by edac_mc_alloc(). Note: The test above shows that edac_mc_alloc() was called here from ghes_edac_register(), thus both functions show up in the stack trace but the module causing the leaks is edac_mc. The comments with the data structures involved were made manually by analyzing the objdump. The data structures listed above and created by edac_mc_alloc() are not properly removed during device removal, which is done in edac_mc_free(). There are two paths implemented to remove the device depending on device registration, _edac_mc_free() is called if the device is not registered and edac_unregister_sysfs() otherwise. The implemenations differ. For the sysfs case, the mci device removal lacks the removal of subsequent data structures (csrows, channels, dimms). This causes the memory leaks (see mci_attr_release()). [ bp: Massage commit message. ] Fixes: c498afaf7df8 ("EDAC: Introduce an mci_for_each_dimm() iterator") Fixes: faa2ad09c01c ("edac_mc: edac_mc_free() cannot assume mem_ctl_info is registered in sysfs.") Fixes: 7a623c039075 ("edac: rewrite the sysfs code to use struct device") Reported-by: John Garry <[email protected]> Signed-off-by: Robert Richter <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Tested-by: John Garry <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-02-13drm: Remove legacy version of get_scanout_position()Thomas Zimmermann3-32/+9
The legacy version of get_scanout_position() was only useful while drivers still used drm_driver.get_scanout_position(). With no such drivers left, the related typedef and code can be removed Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm: Clean-up VBLANK-related callbacks in struct drm_driverThomas Zimmermann3-226/+12
All non-legacy users of VBLANK functions in struct drm_driver have been converted to use the respective interfaces in struct drm_crtc_funcs. The remaining users of VBLANK callbacks in struct drm_driver are legacy drivers with userspace modesetting. All users of struct drm_driver.get_scanout_position() have been converted to the respective CRTC helper function. Remove the callback from struct drm_driver. There are no users left of get_vblank_timestamp(), so the callback is being removed. The other VBLANK callbacks are being moved to the legacy section at the end of struct drm_driver. Also removed is drm_calc_vbltimestamp_from_scanoutpos(). Callers of this function have been converted to use the CRTC instead. v4: * more readable code for setting high_prec (Ville, Jani) v2: * merge with removal of struct drm_driver.get_scanout_position() * remove drm_calc_vbltimestamp_from_scanoutpos() Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Tested-by: Yannick Fertré <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/vmwgfx: Convert to CRTC VBLANK callbacksThomas Zimmermann6-9/+15
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert vmwgfx over. v2: * remove accidental whitespace fixes Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Thomas Hellstrom <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/vkms: Convert to CRTC VBLANK callbacksThomas Zimmermann3-8/+6
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert vkms over. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Tested-by: Rodrigo Siqueira <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/vc4: Convert to CRTC VBLANK callbacksThomas Zimmermann2-2/+1
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert vc4 over. Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/vc4: Convert to struct drm_crtc_helper_funcs.get_scanout_position()Thomas Zimmermann3-10/+7
The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert vc4 over. Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/sti: Convert to CRTC VBLANK callbacksThomas Zimmermann3-9/+8
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert sti over. v2: * remove unnecessary include of sti_crtc.h from sti_drv.c Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Benjamin Gaignard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/stm: Convert to CRTC VBLANK callbacksThomas Zimmermann2-1/+1
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert stm over. Signed-off-by: Thomas Zimmermann <[email protected]> Tested-by: Yannick Fertré <[email protected]> Acked-by: Philippe Cornu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/stm: Convert to struct drm_crtc_helper_funcs.get_scanout_position()Thomas Zimmermann3-42/+39
The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert stm over. Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Philippe Cornu <[email protected]> Tested-by: Yannick Fertré <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/msm: Convert to CRTC VBLANK callbacksThomas Zimmermann6-38/+28
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert msm over. Signed-off-by: Thomas Zimmermann <[email protected]> Tested-by: Yannick Fertré <[email protected]> Acked-by: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/msm: Convert to struct drm_crtc_helper_funcs.get_scanout_position()Thomas Zimmermann2-61/+67
The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert msm over. Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/radeon: Convert to CRTC VBLANK callbacksThomas Zimmermann3-22/+26
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert radeon over. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/radeon: Convert to struct drm_crtc_helper_funcs.get_scanout_position()Thomas Zimmermann5-12/+22
The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert radeon over. v4: * 80-character line fixes Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/nouveau: Convert to CRTC VBLANK callbacksThomas Zimmermann5-18/+11
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert nouvean over. v4: * add argument names in function declaration Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/nouveau: Convert to struct drm_crtc_helper_funcs.get_scanout_position()Thomas Zimmermann5-15/+9
The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert nouveau over. v4: * add argument names in function declaration Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Ben Skeggs <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/i915: Convert to CRTC VBLANK callbacksThomas Zimmermann4-12/+24
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert i915 over. The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). i915 doesn't use CRTC helpers. Instead pass i915's implementation of get_scanout_position() to DRM core's drm_crtc_vblank_helper_get_vblank_timestamp_internal(). v3: * rename dcrtc to _crtc * use intel_ prefix for i915_crtc_get_vblank_timestamp() * update for drm_crtc_vblank_helper_get_vblank_timestamp_internal() v2: * use DRM's implementation of get_vblank_timestamp() * simplify function names Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/gma500: Convert to CRTC VBLANK callbacksThomas Zimmermann6-13/+22
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert gma500 over. Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Patrik Jakobsson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/amdgpu: Convert to CRTC VBLANK callbacksThomas Zimmermann10-22/+43
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert amdgpu over. v2: * don't wrap existing functions; change signature instead Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/amdgpu: Convert to struct drm_crtc_helper_funcs.get_scanout_position()Thomas Zimmermann9-12/+24
The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert amdgpu over. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm: Add get_vblank_timestamp() to struct drm_crtc_funcsThomas Zimmermann4-17/+125
The callback get_vblank_timestamp() is currently located in struct drm_driver, but really belongs into struct drm_crtc_funcs. Add an equivalent there. Driver will be converted in separate patches. The default implementation is drm_calc_vbltimestamp_from_scanoutpos(). The patch adds drm_crtc_vblank_helper_get_vblank_timestamp(), which is an implementation for the CRTC callback. v4: * more readable code for setting high_prec (Ville, Jani) v3: * use refactored timestamp calculation to minimize duplicated code * do more checks for crtc != NULL to support legacy drivers v2: * rename helper to drm_crtc_vblank_helper_get_vblank_timestamp() * replace drm_calc_vbltimestamp_from_scanoutpos() with drm_crtc_vblank_helper_get_vblank_timestamp() in docs Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm: Add get_scanout_position() to struct drm_crtc_helper_funcsThomas Zimmermann4-23/+157
The new callback get_scanout_position() reads the current location of the scanout process. The operation is currently located in struct drm_driver, but really belongs to the CRTC. Drivers will be converted in separate patches. To help with the conversion, the timestamp calculation has been moved from drm_calc_vbltimestamp_from_scanoutpos() to drm_crtc_vblank_helper_get_vblank_timestamp_internal(). The helper function supports the new and old interface of get_scanout_position(). drm_calc_vbltimestamp_from_scanoutpos() remains as a wrapper around the new function. Callback functions return the scanout position from the CRTC. The legacy version of the interface receives the device and pipe index, the modern version receives a pointer to the CRTC. We keep the legacy version until all drivers have been converted. v4: * 80-character line fixes v3: * refactor drm_calc_vbltimestamp_from_scanoutpos() to minimize code duplication * define types for get_scanout_position() callbacks v2: * fix logical op in drm_calc_vbltimestamp_from_scanoutpos() Signed-off-by: Thomas Zimmermann <[email protected]> Tested-by: Yannick Fertré <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm: Remove internal setup of struct drm_device.vblank_disable_immediateThomas Zimmermann1-13/+0
VBLANK interrupts can be disabled immediately or with a delay, where the latter is the default. The former option can be selected by setting get_vblank_timestamp and enabling vblank_disable_immediate in struct drm_device. Simplify the code in preparation of the removal of struct drm_device.get_vblank_timestamp. v3: * remove internal setup of vblank_disable_immediate Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/virtio: fix virtio_gpu_cursor_plane_update().Gerd Hoffmann1-0/+1
Add missing virtio_gpu_array_lock_resv() call. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Chia-I Wu <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/virtio: fix virtio_gpu_execbuffer_ioctl lockingGerd Hoffmann1-10/+10
Lockdep says we can't call vmemdup() while having objects reserved because it needs the mmap semaphore. So reorder the calls reserve the objects later. Signed-off-by: Gerd Hoffmann <[email protected]> Reviewed-by: Chia-I Wu <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/qxl: replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/20200212193344.GA27929@embeddedor Signed-off-by: Gerd Hoffmann <[email protected]>