- Buffer deallocation (+IOCTL) - Buffer reallocation - Private dmabuf user list and accessor
There are possible value truncations when mixing types of different width, e.g. s32 (int), u32, u64. This patch attempts to address such issues in two ways: 1) Manually find and fix error-prone mixing. 2) Prevent creating a handle from an exuberantly large size. The maximum selected size is set to maximum of system memory. This is expected to be small enough that the number of pages fits even in s32. This should offer some future protection in case nvmap starts mixing int and u64 again. Bug 3315168 Change-Id: Icb83d745a7b1955ec473bec46f12a3ae25ad73af Signed-off-by: Martin Radev <mradev@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2537851 (cherry picked from commit 5fa42e9d5f73a937995f87ba28b99d3b891d8f3a) Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2547360 Tested-by: mobile promotions <svcmobile_promotions@nvidia.com> Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
User malloc + mprotect/mmap a buffer as RO and as part of alloc_from_va, user pass the ACCESS_FLAGS as RO and expects NvMap to give dma_buf_fd with RO access. Below are the conditions result in NvRmMemHandle creation - 1) VA: RO and Attr: RW - Don't create NvMap Handle 2) VA: RO and Attr: RO - Create NvMap Handle and set dma_buf_fd as RO 3) VA: RW and Attr: RO - Create NvMap Handle and set dma_buf_fd as RO 4) Mixed VA: RO + RW and Attr: RO - Create NvMap Handle with dma_buf_fd as RO for the whole buffer 5) Mixed VA: RO + RW and Attr: RW - Don't Create NvMap Handle If few pages of the buffer is set as RO and rest as RW, multiple vma are created and vma->end and vma->start doesn't differ by the buffer size, passed to create handle from VA. Hence remove the check. Anyway the check is done in get_user_pages. The change sets dma_buf_fd as RW/RO so that other process should fetch the access permission just by reading f_mode of dma_buf_fd. Bug 200621238 Bug 200634660 Change-Id: I9c50c6f28664f0ff9f70dc08b15d93389e7d7201 Signed-off-by: Puneet Saxena <puneets@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2515023 (cherry picked from commit 0514e68ce8948428b417c55057a4dd2f57acd9c2) Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2521313 Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com> Reviewed-by: Bibek Basu <bbasu@nvidia.com> Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: Amulya Yarlagadda <ayarlagadda@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com> GVS: Gerrit_Virtual_Submit
Add support for coloring pages on T194. Page coloring can improve the memory access perf. Bug 1924977 Change-Id: I586c99a41d93c68ee324158d7ebf4a98d0d2640f Signed-off-by: Alex Van Brunt <avanbrunt@nvidia.com> Signed-off-by: Krishna Reddy <vdumpa@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1747942 Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com> GVS: Gerrit_Virtual_Submit Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Support bigger page size allocations as possible for NvMap allocations. The big page is configurable and is set to 64K as a default. NvMap would try to allcoate 64KB pages before fallback to 4KB page size allocations. Bug 2109966 Change-Id: I2abee7e33417d2a0ece944c4766378946f035b77 Signed-off-by: Krishna Reddy <vdumpa@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1718880 Reviewed-by: Navneet Kumar <navneetk@nvidia.com> GVS: Gerrit_Virtual_Submit Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Cleanup the following obsolete config otpions: NVMAP_HIGHMEM_ONLY NVMAP_PAGE_POOLS_INIT_FILLUP NVMAP_PAGE_POOLS_INIT_FILLUP_SIZE Bug 2110982 Change-Id: I37505366c4026883bb04d20f698b013f998ca0c1 Signed-off-by: Krishna Reddy <vdumpa@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1705733 Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com> GVS: Gerrit_Virtual_Submit Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Bug 2110982 Change-Id: I026c5b0be606d5e9d98b048a4f160ef591efcecb Signed-off-by: Krishna Reddy <vdumpa@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1705783 Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Report the error reported by get_user_pages (gup) correctly. While at it, simplify the cleanup code associated with it. Bug 1784061 Change-Id: Iead6bc4701e11dfb7c30fb2fe1d6dd2c3e2789f8 Signed-off-by: Navneet Kumar <navneetk@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1701725 Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com> Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com> Reviewed-by: Krishna Reddy <vdumpa@nvidia.com> GVS: Gerrit_Virtual_Submit Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
zero_memory_set() API in nvmap_alloc is not getting used anywhere. Hence removing it. This will improve code coverage. Bug 200386771 Change-Id: I4750c5d3984c45c46d4b0fb72348b831944deecc Signed-off-by: Ashish Mhetre <amhetre@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1665746 Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Fix a bug causing carveout Virtual Addresses to not be freed when the handle was lazily unmapped Change-Id: I5f2442b7e2cccacfaf7721eed6c7e630bc1f30a4 Signed-off-by: David Gilhooley <dgilhooley@nvidia.com> Reviewed-on: https://git-master.nvidia.com/r/1641681 Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com> GVS: Gerrit_Virtual_Submit Reviewed-by: Krishna Reddy <vdumpa@nvidia.com> Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com> Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>