aboutsummaryrefslogtreecommitdiff
path: root/drivers/misc
AgeCommit message (Collapse)AuthorFilesLines
2022-05-22habanalabs: unified memory manager infrastructureYuri Nudelman3-1/+333
This is a part of overall refactoring attempt to separate nic and the core drivers. Currently, there are 4 different flows, that contain very similar code. These are the ts, nic, hwblocks and cb alloc/map flows. The similar aspect of all these flows is that they all contain a central store, with memory buffers inside, supporting the following set of operations: - Allocate buffer and return handle - Get buffer from the store with handle - Put the buffer (last put releases the buffer) - Map the buffer to the user This patch contains a generic data structure used to implement the above memory buffer store interface. Conversion of the existing code to use the new data structure will follow. Signed-off-by: Yuri Nudelman <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs: save f/w preboot major versionOfir Bitton2-10/+22
We need this property for doing backward compatibility hacks against the f/w. Signed-off-by: Ofir Bitton <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs: replace usage of found with dedicated list iterator variableJakob Koschel1-6/+5
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable instead of a found boolean [1]. This removes the need to use a found variable and simply checking if the variable was set, can determine if the break/goto was hit. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ Signed-off-by: Jakob Koschel <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs: modify dma_mask to be ASIC specific propertyTomer Tayar5-30/+10
The required DMA mask is no longer based on input from the F/W, but it is fixed per ASIC according to its address space. As such, the per-ASIC function to get this value can be replaced with a property variable. Signed-off-by: Tomer Tayar <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs: parse full firmware versionsOfir Bitton1-2/+4
When parsing firmware versions strings, driver should not assume a specific length and parse up to the maximum supported version length. Signed-off-by: Ofir Bitton <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs/gaudi: avoid resetting max power in hard resetTomer Tayar1-2/+0
The default max power is deduced from the card type value in the CPU-CP info. This value is then set in the max power variable of the device structure. Getting the CPU-CP info is done as part of the late init phase which is called also during reset. This means that a max power value which is modified via sysfs will be reset during hard reset back to the default value. As the max power is updated in any case during device init in hl_sysfs_init(), this setting in late init can be removed, and the overriding during reset is thus avoided. Signed-off-by: Tomer Tayar <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs/gaudi: increase submission resourcesOfir Bitton1-2/+2
In order to allow user to have larger amount of submissions, we increase the DMA and NIC queue depth to 4K. Signed-off-by: Ofir Bitton <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs: expose compute ctx status through info ioctlOfir Bitton1-0/+2
In order for the user to know if he can try and open device, we expose the compute ctx state. The user can now know if the context is used by another process or whether the device is still ongoing through cleanup or reset and will be available soon. Signed-off-by: Ofir Bitton <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs: add new return code to device fd openOfir Bitton3-1/+20
In order to be more informative during device open, we are adding a new return code -EAGAIN that indicates device is still going through resource reclaiming and hence it cannot be used yet. Signed-off-by: Ofir Bitton <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs: add user API to get valid DRAM page sizesOhad Sharabi4-0/+40
Future devices will support multiple device memory page sizes. In addition, an API for the user was added for it to be able to control the device memory allocation page size. This patch is a complementary patch to inform the user of the available page size supported by the device. Signed-off-by: Ohad Sharabi <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs: convert all MMU masks/shifts to arraysOhad Sharabi6-92/+52
There is no need to hold each MMU mask/shift as a denoted structure member (e.g. hop0_mask). Instead converting it to array will result in smaller and more readable code. Signed-off-by: Ohad Sharabi <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs: change mmu_get_real_page_size to be ASIC-specificOhad Sharabi4-98/+112
This patch breaks the cumbersome implementation of "get real page size" along with it's multiple inner conditions and implement each case (according to the real complexity) inside an ASIC function. Signed-off-by: Ohad Sharabi <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs: add DRAM default page size to HW infoOhad Sharabi1-0/+1
When using the device memory allocation API the user ought to know what is the default allocation page size. Signed-off-by: Ohad Sharabi <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-22habanalabs: set non-0 value in dram default page sizeOhad Sharabi4-1/+8
Looking forward we will need to report to the user what is the default page size used. This will be done more conveniently by explicitly updating the property rather than to rely on a "0 meaning default" value. Signed-off-by: Ohad Sharabi <[email protected]> Reviewed-by: Oded Gabbay <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-19misc: fastrpc: fix list iterator in fastrpc_req_mem_unmap_implSrinivas Kandagatla1-4/+5
This is another instance of incorrect use of list iterator and checking it for NULL. The list iterator value 'map' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty (in this case, the check 'if (!map) {' will always be false and never exit as expected). To fix the bug, use a new variable 'iter' as the list iterator, while use the original variable 'map' as a dedicated pointer to point to the found element. Without this patch, Kernel crashes with below trace: Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000ffff7fb03750 ... Call trace: fastrpc_map_create+0x70/0x290 [fastrpc] fastrpc_req_mem_map+0xf0/0x2dc [fastrpc] fastrpc_device_ioctl+0x138/0xc60 [fastrpc] __arm64_sys_ioctl+0xa8/0xec invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xd4/0xfc do_el0_svc+0x28/0x90 el0_svc+0x3c/0x130 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x18c/0x190 Code: 14000016 f94000a5 eb05029f 54000260 (b94018a6) ---[ end trace 0000000000000000 ]--- Fixes: 5c1b97c7d7b7 ("misc: fastrpc: add support for FASTRPC_IOCTL_MEM_MAP/UNMAP") Cc: [email protected] Reported-by: Jan Jablonsky <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-19misc: alcor_pci: set NULL intfdata and clear pci masterShuah Khan1-1/+5
alcor_pci doesn't set driver data to NULL and clear pci master when probe fails. Doesn't clear pci master from remove interface. Clearing pci master is necessary to disable bus mastering and prevent DMAs after driver removal. Fix alcor_pci_probe() to set driver data to NULL and clear pci master from its error path. Fix alcor_pci_remove() to clear pci master. Signed-off-by: Shuah Khan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-19Merge tag 'thunderbolt-for-v5.19-rc1' of ↵Greg Kroah-Hartman2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next Mika writes: thunderbolt: Changes for v5.19 merge window This includes following Thunderbolt/USB4 changes for the v5.19 merge window: * Improvements for Thunderbolt 1 DisplayPort tunneling * Link USB4 ports to their USB Type-C connectors * Lane bonding support for host-to-host (XDomain) connections * Buffer allocation improvement for devices with no DisplayPort adapters * Few cleanups and minor fixes. All these have been in linux-next with no reported issues except that there is a minor merge conflict with the kunit-next tree because one of the commits touches the driver KUnit tests. * tag 'thunderbolt-for-v5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Add KUnit test for devices with no DisplayPort adapters thunderbolt: Fix buffer allocation of devices with no DisplayPort adapters thunderbolt: Add support for XDomain lane bonding thunderbolt: Ignore port locked error in tb_port_wait_for_link_width() thunderbolt: Split setting link width and lane bonding into own functions thunderbolt: Move tb_port_state() prototype to correct place thunderbolt: Add debug logging when lane is enabled/disabled thunderbolt: Link USB4 ports to their USB Type-C connectors misc/mei: Add NULL check to component match callback functions thunderbolt: Use different lane for second DisplayPort tunnel thunderbolt: Dump path config space entries during discovery thunderbolt: Use decimal number with port numbers thunderbolt: Fix typo in comment thunderbolt: Replace usage of found with dedicated list iterator variable
2022-05-19Merge tag 'lkdtm-next' of ↵Greg Kroah-Hartman2-15/+99
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into char-misc-next Kees writes: lkdtm updates for -next - Test for new usercopy memory regions - avoid GCC 12 warnings - update expected CONFIGs for selftests * tag 'lkdtm-next' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: lkdtm/heap: Hide allocation size from -Warray-bounds selftests/lkdtm: Add configs for stackleak and "after free" tests lkdtm/usercopy: Check vmalloc and >0-order folios lkdtm/usercopy: Rename "heap" to "slab" lkdtm: cfi: Fix type width for masking PAC bits
2022-05-17lkdtm/heap: Hide allocation size from -Warray-boundsKees Cook1-0/+1
With the kmalloc() size annotations, GCC is smart enough to realize that LKDTM is intentionally writing past the end of the buffer. This is on purpose, of course, so hide the buffer from the optimizer. Silences: ../drivers/misc/lkdtm/heap.c: In function 'lkdtm_SLAB_LINEAR_OVERFLOW': ../drivers/misc/lkdtm/heap.c:59:13: warning: array subscript 256 is outside array bounds of 'void[1020]' [-Warray-bounds] 59 | data[1024 / sizeof(u32)] = 0x12345678; | ~~~~^~~~~~~~~~~~~~~~~~~~ In file included from ../drivers/misc/lkdtm/heap.c:7: In function 'kmalloc', inlined from 'lkdtm_SLAB_LINEAR_OVERFLOW' at ../drivers/misc/lkdtm/heap.c:54:14: ../include/linux/slab.h:581:24: note: at offset 1024 into object of size 1020 allocated by 'kmem_cache_alloc_trace' 581 | return kmem_cache_alloc_trace( | ^~~~~~~~~~~~~~~~~~~~~~~ 582 | kmalloc_caches[kmalloc_type(flags)][index], | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 583 | flags, size); | ~~~~~~~~~~~~ Cc: Greg Kroah-Hartman <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Kees Cook <[email protected]>
2022-05-17lkdtm/usercopy: Check vmalloc and >0-order foliosKees Cook1-0/+83
Add coverage for the recently added usercopy checks for vmalloc and folios, via USERCOPY_VMALLOC and USERCOPY_FOLIO respectively. Cc: Greg Kroah-Hartman <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Kees Cook <[email protected]>
2022-05-11lkdtm/usercopy: Rename "heap" to "slab"Kees Cook1-15/+15
To more clearly distinguish between the various heap types, rename the slab tests to "slab". Cc: Arnd Bergmann <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Shuah Khan <[email protected]> Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2022-05-11cxl/ocxl: Prepare cleanup of powerpc's asm/prom.hChristophe Leroy10-0/+12
powerpc's asm/prom.h brings some headers that it doesn't need itself. In order to clean it up, first add missing headers in users of asm/prom.h Signed-off-by: Christophe Leroy <[email protected]> Acked-by: Frederic Barrat <[email protected]> Acked-by: Andrew Donnellan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/a2bae89b280e7a7cb87889635d9911d6a245e780.1648833388.git.christophe.leroy@csgroup.eu
2022-05-09lkdtm: cfi: Fix type width for masking PAC bitsKees Cook1-1/+1
The masking for PAC bits wasn't handling 32-bit architectures correctly. Replace the u64 cast with uintptr_t. Link: https://lore.kernel.org/lkml/CAMuHMdVz-J-1ZQ08u0bsQihDkcRmEPrtX5B_oRJ+Ns5jrasnUw@mail.gmail.com Fixes: 2e53b877dc12 ("lkdtm: Add CFI_BACKWARD to test ROP mitigations") Cc: Greg Kroah-Hartman <[email protected]> Cc: Arnd Bergmann <[email protected]> Reported-by: kernel test robot <[email protected]> Reported-by: Geert Uytterhoeven <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Tested-by: Randy Dunlap <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-09misc: rtsx: set NULL intfdata when probe failsShuah Khan1-0/+1
rtsx_usb_probe() doesn't call usb_set_intfdata() to null out the interface pointer when probe fails. This leaves a stale pointer. Noticed the missing usb_set_intfdata() while debugging an unrelated invalid DMA mapping problem. Fix it with a call to usb_set_intfdata(..., NULL). Signed-off-by: Shuah Khan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-09altera-stapl: Use swap() instead of open coding itJiapeng Chong1-40/+16
Clean the following coccicheck warning: ./drivers/misc/altera-stapl/altera.c:955:51-52: WARNING opportunity for swap(). Reported-by: Abaci Robot <[email protected]> Signed-off-by: Jiapeng Chong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-09misc: rtsx: add rts5261 efuse functionRicky WU1-53/+62
move rts5261_fetch_vendor_settings() to rts5261_init_from_hw() make sure it be called from S3 or D3 add more register setting when efuse is set read efuse setting to register on init flow Signed-off-by: Ricky Wu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-05-08lkdtm/stackleak: fix CONFIG_GCC_PLUGIN_STACKLEAK=nMark Rutland1-1/+11
Recent rework broke building LKDTM when CONFIG_GCC_PLUGIN_STACKLEAK=n. This patch fixes that breakage. Prior to recent stackleak rework, the LKDTM STACKLEAK_ERASING code could be built when the kernel was not built with stackleak support, and would run a test that would almost certainly fail (or pass by sheer cosmic coincidence), e.g. | # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT | lkdtm: Performing direct entry STACKLEAK_ERASING | lkdtm: checking unused part of the thread stack (15560 bytes)... | lkdtm: FAIL: the erased part is not found (checked 15560 bytes) | lkdtm: FAIL: the thread stack is NOT properly erased! | lkdtm: This is probably expected, since this kernel (5.18.0-rc2 aarch64) was built *without* CONFIG_GCC_PLUGIN_STACKLEAK=y The recent rework to the test made it more accurate by using helpers which are only defined when CONFIG_GCC_PLUGIN_STACKLEAK=y, and so when building LKDTM when CONFIG_GCC_PLUGIN_STACKLEAK=n, we get a build failure: | drivers/misc/lkdtm/stackleak.c: In function 'check_stackleak_irqoff': | drivers/misc/lkdtm/stackleak.c:30:46: error: implicit declaration of function 'stackleak_task_low_bound' [-Werror=implicit-function-declaration] | 30 | const unsigned long task_stack_low = stackleak_task_low_bound(current); | | ^~~~~~~~~~~~~~~~~~~~~~~~ | drivers/misc/lkdtm/stackleak.c:31:47: error: implicit declaration of function 'stackleak_task_high_bound'; did you mean 'stackleak_task_init'? [-Werror=implicit-function-declaration] | 31 | const unsigned long task_stack_high = stackleak_task_high_bound(current); | | ^~~~~~~~~~~~~~~~~~~~~~~~~ | | stackleak_task_init | drivers/misc/lkdtm/stackleak.c:33:48: error: 'struct task_struct' has no member named 'lowest_stack' | 33 | const unsigned long lowest_sp = current->lowest_stack; | | ^~ | drivers/misc/lkdtm/stackleak.c:74:23: error: implicit declaration of function 'stackleak_find_top_of_poison' [-Werror=implicit-function-declaration] | 74 | poison_high = stackleak_find_top_of_poison(task_stack_low, untracked_high); | | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ This patch fixes the issue by not compiling the body of the test when CONFIG_GCC_PLUGIN_STACKLEAK=n, and replacing this with an unconditional XFAIL message. This means the pr_expected_config() in check_stackleak_irqoff() is redundant, and so it is removed. Where an architecture does not support stackleak, the test will log: | # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT | lkdtm: Performing direct entry STACKLEAK_ERASING | lkdtm: XFAIL: stackleak is not supported on this arch (HAVE_ARCH_STACKLEAK=n) Where an architectures does support stackleak, but this has not been compiled in, the test will log: | # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT | lkdtm: Performing direct entry STACKLEAK_ERASING | lkdtm: XFAIL: stackleak is not enabled (CONFIG_GCC_PLUGIN_STACKLEAK=n) Where stackleak has been compiled in, the test behaves as usual: | # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT | lkdtm: Performing direct entry STACKLEAK_ERASING | lkdtm: stackleak stack usage: | high offset: 336 bytes | current: 688 bytes | lowest: 1232 bytes | tracked: 1232 bytes | untracked: 672 bytes | poisoned: 14136 bytes | low offset: 8 bytes | lkdtm: OK: the rest of the thread stack is properly erased Fixes: f4cfacd92972cc44 ("lkdtm/stackleak: rework boundary management") Signed-off-by: Mark Rutland <[email protected]> Cc: Alexander Popov <[email protected]> Cc: Kees Cook <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-08lkdtm/stackleak: check stack boundariesMark Rutland1-0/+20
The stackleak code relies upon the current SP and lowest recorded SP falling within expected task stack boundaries. Check this at the start of the test. Signed-off-by: Mark Rutland <[email protected]> Cc: Alexander Popov <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Kees Cook <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-08lkdtm/stackleak: prevent unexpected stack usageMark Rutland1-1/+23
The lkdtm_STACKLEAK_ERASING() test is instrumentable and runs with IRQs unmasked, so it's possible for unrelated code to clobber the task stack and/or manipulate current->lowest_stack while the test is running, resulting in spurious failures. The regular stackleak erasing code is non-instrumentable and runs with IRQs masked, preventing similar issues. Make the body of the test non-instrumentable, and run it with IRQs masked, avoiding such spurious failures. Signed-off-by: Mark Rutland <[email protected]> Cc: Alexander Popov <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Kees Cook <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-08lkdtm/stackleak: rework boundary managementMark Rutland1-39/+47
There are a few problems with the way the LKDTM STACKLEAK_ERASING test manipulates the stack pointer and boundary values: * It uses the address of a local variable to determine the current stack pointer, rather than using current_stack_pointer directly. As the local variable could be placed anywhere within the stack frame, this can be an over-estimate of the true stack pointer value. * Is uses an estimate of the current stack pointer as the upper boundary when scanning for poison, even though prior functions could have used more stack (and may have updated current->lowest stack accordingly). * A pr_info() call is made in the middle of the test. As the printk() code is out-of-line and will make use of the stack, this could clobber poison and/or adjust current->lowest_stack. It would be better to log the metadata after the body of the test to avoid such problems. These have been observed to result in spurious test failures on arm64. In addition to this there are a couple of things which are sub-optimal: * To avoid the STACK_END_MAGIC value, it conditionally modifies 'left' if this contains more than a single element, when it could instead calculate the bound unconditionally using stackleak_task_low_bound(). * It open-codes the poison scanning. It would be better if this used the same helper code as used by erasing function so that the two cannot diverge. This patch reworks the test to avoid these issues, making use of the recently introduced helpers to ensure this is aligned with the regular stackleak code. As the new code tests stack boundaries before accessing the stack, there is no need to fail early when the tracked or untracked portions of the stack extend all the way to the low stack boundary. As stackleak_find_top_of_poison() is now used to find the top of the poisoned region of the stack, the subsequent poison checking starts at this boundary and verifies that stackleak_find_top_of_poison() is working correctly. The pr_info() which logged the untracked portion of stack is now moved to the end of the function, and logs the size of all the portions of the stack relevant to the test, including the portions at the top and bottom of the stack which are not erased or scanned, and the current / lowest recorded stack usage. Tested on x86_64: | # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT | lkdtm: Performing direct entry STACKLEAK_ERASING | lkdtm: stackleak stack usage: | high offset: 168 bytes | current: 336 bytes | lowest: 656 bytes | tracked: 656 bytes | untracked: 400 bytes | poisoned: 15152 bytes | low offset: 8 bytes | lkdtm: OK: the rest of the thread stack is properly erased Tested on arm64: | # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT | lkdtm: Performing direct entry STACKLEAK_ERASING | lkdtm: stackleak stack usage: | high offset: 336 bytes | current: 656 bytes | lowest: 1232 bytes | tracked: 1232 bytes | untracked: 672 bytes | poisoned: 14136 bytes | low offset: 8 bytes | lkdtm: OK: the rest of the thread stack is properly erased Tested on arm64 with deliberate breakage to the starting stack value and poison scanning: | # echo STACKLEAK_ERASING > /sys/kernel/debug/provoke-crash/DIRECT | lkdtm: Performing direct entry STACKLEAK_ERASING | lkdtm: FAIL: non-poison value 24 bytes below poison boundary: 0x0 | lkdtm: FAIL: non-poison value 32 bytes below poison boundary: 0xffff8000083dbc00 ... | lkdtm: FAIL: non-poison value 1912 bytes below poison boundary: 0x78b4b9999e8cb15 | lkdtm: FAIL: non-poison value 1920 bytes below poison boundary: 0xffff8000083db400 | lkdtm: stackleak stack usage: | high offset: 336 bytes | current: 688 bytes | lowest: 1232 bytes | tracked: 576 bytes | untracked: 288 bytes | poisoned: 15176 bytes | low offset: 8 bytes | lkdtm: FAIL: the thread stack is NOT properly erased! | lkdtm: Unexpected! This kernel (5.18.0-rc1-00013-g1f7b1f1e29e0-dirty aarch64) was built with CONFIG_GCC_PLUGIN_STACKLEAK=y Signed-off-by: Mark Rutland <[email protected]> Cc: Alexander Popov <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Kees Cook <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-08lkdtm/stackleak: avoid spurious failureMark Rutland1-7/+0
The lkdtm_STACKLEAK_ERASING() test scans for a contiguous block of poison values between the low stack bound and the stack pointer, and fails if it does not find a sufficiently large block. This can happen legitimately if the scan the low stack bound, which could occur if functions called prior to lkdtm_STACKLEAK_ERASING() used a large amount of stack. If this were to occur, it means that the erased portion of the stack is smaller than the size used by the scan, but does not cause a functional problem In practice this is unlikely to happen, but as this is legitimate and would not result in a functional problem, the test should not fail in this case. Remove the spurious failure case. Signed-off-by: Mark Rutland <[email protected]> Cc: Alexander Popov <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Kees Cook <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-05-03Backmerge tag 'v5.18-rc5' of ↵Dave Airlie1-8/+11
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next Linux 5.18-rc5 There was a build fix for arm I wanted in drm-next, so backmerge rather then cherry-pick. Signed-off-by: Dave Airlie <[email protected]>
2022-05-02Merge 5.18-rc5 into char-misc-nextGreg Kroah-Hartman1-8/+11
We need the char-misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-04-29misc/pvpanic: Convert regular spinlock into trylock on panic pathGuilherme G. Piccoli1-2/+8
The pvpanic driver relies on panic notifiers to execute a callback on panic event. Such function is executed in atomic context - the panic function disables local IRQs, preemption and all other CPUs that aren't running the panic code. With that said, it's dangerous to use regular spinlocks in such path, as introduced by commit b3c0f8774668 ("misc/pvpanic: probe multiple instances"). This patch fixes that by replacing regular spinlocks with the trylock safer approach. It also fixes an old comment (about a long gone framebuffer code) and the notifier priority - we should execute hypervisor notifiers early, deferring this way the panic action to the hypervisor, as expected by the users that are setting up pvpanic. Fixes: b3c0f8774668 ("misc/pvpanic: probe multiple instances") Cc: Christophe JAILLET <[email protected]> Cc: Mihai Carabas <[email protected]> Cc: Shile Zhang <[email protected]> Cc: Wang ShaoBo <[email protected]> Cc: zhenwei pi <[email protected]> Signed-off-by: Guilherme G. Piccoli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-04-29misc/mei: Add NULL check to component match callback functionsWon Chung2-2/+2
Currently, component_match callback functions used in mei refers to the driver name, assuming that the component device being matched has a driver bound. It can cause a NULL pointer dereference when a device without a driver bound registers a component. This is due to the nature of the component framework where all registered components are matched in any component_match callback functions. So even if a component is registered by a totally irrelevant device, that component is also shared to these callbacks for i915 driver. To prevent totally irrelevant device being matched for i915 and causing a NULL pointer dereference for checking driver name, add a NULL check on dev->driver to check if there is a driver bound before checking the driver name. In the future, the string compare on the driver name, "i915" may need to be refactored too. Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Prashant Malani <[email protected]> Signed-off-by: Won Chung <[email protected]> Acked-by: Tomas Winkler <[email protected]> Signed-off-by: Mika Westerberg <[email protected]>
2022-04-29Merge tag 'drm-misc-next-2022-04-28' of ↵Dave Airlie1-1/+1
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.19: UAPI Changes: Cross-subsystem Changes: Core Changes: - Introduction of display-helper module, and rework of the DP, DSC, HDCP, HDMI and SCDC headers - doc: Improvements for tiny drivers, link to external resources - formats: helper to convert from RGB888 and RGB565 to XRGB8888 - modes: make width-mm/height-mm check mandatory in of_get_drm_panel_display_mode - ttm: Convert from kvmalloc_array to kvcalloc Driver Changes: - bridge: - analogix_dp: Fix error handling in probe - dw_hdmi: Coccinelle fixes - it6505: Fix Kconfig dependency on DRM_DP_AUX_BUS - panel: - new panel: DataImage FG040346DSSWBG04 - amdgpu: ttm_eu cleanups - mxsfb: Rework CRTC mode setting - nouveau: Make some variables static - sun4i: Drop drm_display_info.is_hdmi caching, support for the Allwinner D1 - vc4: Drop drm_display_info.is_hdmi caching - vmwgfx: Fence improvements Signed-off-by: Dave Airlie <[email protected]> # gpg: Signature made Thu 28 Apr 2022 17:52:13 AEST # gpg: using EDDSA key 5C1337A45ECA9AEB89060E9EE3EF0D6F671851C5 # gpg: Can't check signature: No public key From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20220428075237.yypztjha7hetphcd@houat
2022-04-26lkdtm: cfi: Fix type width for masking PAC bitsKees Cook1-1/+1
The masking for PAC bits wasn't handling 32-bit architectures correctly. Replace the u64 cast with uintptr_t. Reported-by: kernel test robot <[email protected]> Reported-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/lkml/CAMuHMdVz-J-1ZQ08u0bsQihDkcRmEPrtX5B_oRJ+Ns5jrasnUw@mail.gmail.com Fixes: 2e53b877dc12 ("lkdtm: Add CFI_BACKWARD to test ROP mitigations") Cc: Greg Kroah-Hartman <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Kees Cook <[email protected]>
2022-04-25drm/display: Move HDCP helpers into display-helper moduleThomas Zimmermann1-1/+1
Move DRM's HDCP helper library into the display/ subdirectory and add it to DRM's display helpers. Split the header file into core and helpers. Update all affected drivers. No functional changes. v3: * fix Kconfig dependencies v2: * fix include statements (Jani, Javier) * update Kconfig symbols Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-24VMCI: Add support for ARM64Vishnu Dasa3-1/+17
Add support for ARM64 architecture so that the driver can now be built and VMCI device can be used. Update Kconfig file to allow the driver to be built on ARM64 as well. Fail vmci_guest_probe_device() on ARM64 if the device does not support MMIO register access. Lastly, add virtualization specific barriers which map to actual memory barrier instructions on ARM64, because it is required in case of ARM64 for queuepair (de)queuing. Reviewed-by: Bryan Tan <[email protected]> Reviewed-by: Cyprien Laplace <[email protected]> Signed-off-by: Vishnu Dasa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-04-24misc: bcm-vk: replace usage of found with dedicated list iterator variableJakob Koschel1-16/+13
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable instead of a found boolean [1]. This removes the need to use a found variable and simply checking if the variable was set, can determine if the break/goto was hit. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ Signed-off-by: Jakob Koschel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-04-24eeprom: at25: Use DMA safe buffersChristophe Leroy1-8/+11
Reading EEPROM fails with following warning: [ 16.357496] ------------[ cut here ]------------ [ 16.357529] fsl_spi b01004c0.spi: rejecting DMA map of vmalloc memory [ 16.357698] WARNING: CPU: 0 PID: 371 at include/linux/dma-mapping.h:326 fsl_spi_cpm_bufs+0x2a0/0x2d8 [ 16.357775] CPU: 0 PID: 371 Comm: od Not tainted 5.16.11-s3k-dev-01743-g19beecbfe9d6-dirty #109 [ 16.357806] NIP: c03fbc9c LR: c03fbc9c CTR: 00000000 [ 16.357825] REGS: e68d9b20 TRAP: 0700 Not tainted (5.16.11-s3k-dev-01743-g19beecbfe9d6-dirty) [ 16.357849] MSR: 00029032 <EE,ME,IR,DR,RI> CR: 24002282 XER: 00000000 [ 16.357931] [ 16.357931] GPR00: c03fbc9c e68d9be0 c26d06a0 00000039 00000001 c0d36364 c0e96428 00000027 [ 16.357931] GPR08: 00000001 00000000 00000023 3fffc000 24002282 100d3dd6 100a2ffc 00000000 [ 16.357931] GPR16: 100cd280 100b0000 00000000 aff54f7e 100d0000 100d0000 00000001 100cf328 [ 16.357931] GPR24: 100cf328 00000000 00000003 e68d9e30 c156b410 e67ab4c0 e68d9d38 c24ab278 [ 16.358253] NIP [c03fbc9c] fsl_spi_cpm_bufs+0x2a0/0x2d8 [ 16.358292] LR [c03fbc9c] fsl_spi_cpm_bufs+0x2a0/0x2d8 [ 16.358325] Call Trace: [ 16.358336] [e68d9be0] [c03fbc9c] fsl_spi_cpm_bufs+0x2a0/0x2d8 (unreliable) [ 16.358388] [e68d9c00] [c03fcb44] fsl_spi_bufs.isra.0+0x94/0x1a0 [ 16.358436] [e68d9c20] [c03fd970] fsl_spi_do_one_msg+0x254/0x3dc [ 16.358483] [e68d9cb0] [c03f7e50] __spi_pump_messages+0x274/0x8a4 [ 16.358529] [e68d9ce0] [c03f9d30] __spi_sync+0x344/0x378 [ 16.358573] [e68d9d20] [c03fb52c] spi_sync+0x34/0x60 [ 16.358616] [e68d9d30] [c03b4dec] at25_ee_read+0x138/0x1a8 [ 16.358667] [e68d9e50] [c04a8fb8] bin_attr_nvmem_read+0x98/0x110 [ 16.358725] [e68d9e60] [c0204b14] kernfs_fop_read_iter+0xc0/0x1fc [ 16.358774] [e68d9e80] [c0168660] vfs_read+0x284/0x410 [ 16.358821] [e68d9f00] [c016925c] ksys_read+0x6c/0x11c [ 16.358863] [e68d9f30] [c00160e0] ret_from_syscall+0x0/0x28 ... [ 16.359608] ---[ end trace a4ce3e34afef0cb5 ]--- [ 16.359638] fsl_spi b01004c0.spi: unable to map tx dma This is due to the AT25 driver using buffers on stack, which is not possible with CONFIG_VMAP_STACK. As mentionned in kernel Documentation (Documentation/spi/spi-summary.rst): - Follow standard kernel rules, and provide DMA-safe buffers in your messages. That way controller drivers using DMA aren't forced to make extra copies unless the hardware requires it (e.g. working around hardware errata that force the use of bounce buffering). Modify the driver to use a buffer located in the at25 device structure which is allocated via kmalloc during probe. Protect writes in this new buffer with the driver's mutex. Fixes: b587b13a4f67 ("[PATCH] SPI eeprom driver") Cc: stable <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Link: https://lore.kernel.org/r/230a9486fc68ea0182df46255e42a51099403642.1648032613.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-04-24misc: fastrpc: fix an incorrect NULL check on list iteratorXiaomeng Tong1-4/+5
The bug is here: if (!buf) { The list iterator value 'buf' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty (in this case, the check 'if (!buf) {' will always be false and never exit expectly). To fix the bug, use a new variable 'iter' as the list iterator, while use the original variable 'buf' as a dedicated pointer to point to the found element. Fixes: 2419e55e532de ("misc: fastrpc: add mmap/unmap support") Signed-off-by: Xiaomeng Tong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-04-24misc: vmw_vmci: replace usage of found with dedicated list iterator variableJakob Koschel1-8/+7
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable instead of a found boolean [1]. This removes the need to use a found variable and simply checking if the variable was set, can determine if the break/goto was hit. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ Signed-off-by: Jakob Koschel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-04-24vmw_balloon: Print errors on reset only onceNadav Amit1-2/+2
The VMware balloon might be reset multiple times during execution. Print errors only once to avoid filling the log unnecessarily. Signed-off-by: Nadav Amit <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-04-21mei: gsc: retrieve the firmware versionAlexander Usyskin2-0/+27
Add a hook to retrieve the firmware version of the GSC devices to bus-fixup. GSC has a different MKHI clients GUIDs but the same message structure to retrieve the firmware version as MEI so mei_fwver() can be reused. CC: Ashutosh Dixit <[email protected]> Signed-off-by: Alexander Usyskin <[email protected]> Signed-off-by: Tomas Winkler <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-21mei: gsc: add runtime pm handlersTomas Winkler1-1/+66
Implement runtime handlers for mei-gsc, to track idle state of the device properly. CC: Rodrigo Vivi <[email protected]> Signed-off-by: Tomas Winkler <[email protected]> Signed-off-by: Alexander Usyskin <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-21mei: gsc: setup char driver alive in spite of firmware handshake failureAlexander Usyskin1-6/+6
Setup char device in spite of firmware handshake failure. In order to provide host access to the firmware status registers and other information required for the manufacturing process. Signed-off-by: Alexander Usyskin <[email protected]> Signed-off-by: Tomas Winkler <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-21mei: add support for graphics system controller (gsc) devicesTomas Winkler5-2/+238
GSC is a graphics system controller, based on CSE, it provides a chassis controller for graphics discrete cards, as well as it supports media protection on selected devices. mei_gsc binds to a auxiliary devices exposed by Intel discrete driver i915. v2: fix error check in mei_gsc_probe v3: update MODULE_LICENSE ("GPL" is preferred over "GPL v2" and they both map to GPL version 2) Signed-off-by: Alexander Usyskin <[email protected]> Signed-off-by: Tomas Winkler <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> #v3 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-21misc: ocxl: fix possible double free in ocxl_file_register_afuHangyu Hua1-0/+2
info_release() will be called in device_unregister() when info->dev's reference count is 0. So there is no need to call ocxl_afu_put() and kfree() again. Fix this by adding free_minor() and return to err_unregister error path. Fixes: 75ca758adbaf ("ocxl: Create a clear delineation between ocxl backend & frontend") Signed-off-by: Hangyu Hua <[email protected]> Acked-by: Frederic Barrat <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-04-16lkdtm: Add CFI_BACKWARD to test ROP mitigationsKees Cook1-0/+134
In order to test various backward-edge control flow integrity methods, add a test that manipulates the return address on the stack. Currently only arm64 Pointer Authentication and Shadow Call Stack is supported. $ echo CFI_BACKWARD | cat >/sys/kernel/debug/provoke-crash/DIRECT Under SCS, successful test of the mitigation is reported as: lkdtm: Performing direct entry CFI_BACKWARD lkdtm: Attempting unchecked stack return address redirection ... lkdtm: ok: redirected stack return address. lkdtm: Attempting checked stack return address redirection ... lkdtm: ok: control flow unchanged. Under PAC, successful test of the mitigation is reported by the PAC exception handler: lkdtm: Performing direct entry CFI_BACKWARD lkdtm: Attempting unchecked stack return address redirection ... lkdtm: ok: redirected stack return address. lkdtm: Attempting checked stack return address redirection ... Unable to handle kernel paging request at virtual address bfffffc0088d0514 Mem abort info: ESR = 0x86000004 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault [bfffffc0088d0514] address between user and kernel address ranges ... If the CONFIGs are missing (or the mitigation isn't working), failure is reported as: lkdtm: Performing direct entry CFI_BACKWARD lkdtm: Attempting unchecked stack return address redirection ... lkdtm: ok: redirected stack return address. lkdtm: Attempting checked stack return address redirection ... lkdtm: FAIL: stack return address was redirected! lkdtm: This is probably expected, since this kernel was built *without* CONFIG_ARM64_PTR_AUTH_KERNEL=y nor CONFIG_SHADOW_CALL_STACK=y Co-developed-by: Dan Li <[email protected]> Signed-off-by: Dan Li <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.