There is a potential data race for RO dma-buf in the following scenario:
------------------------------------------------------------------
Process 1 | Process 2 | Process 3 |
------------------------------------------------------------------|
AllocAttr handle H1 | | |
MemMap (H1) | | |
AllocAttr(H2) | | |
MemMap(H2) | | |
id1 = GetSciIpcId(H1)| | |
id2 = GetSciIpcId(H2)|H3=HandleFromSciIpcId | |
id3 = GetSciIpcId(H1)| (id1, RO) |H4=HandleFromSciIpcId|
MemUnmap(H2) |QueryHandlePararms(H3)|(id2, RO) |
MemUnmap(H1) |MemMap(H3) |QueryHandleParams(H4)|
HandleFree(H2) |MemUnmap(H3) |MemMap(H4) |
HandleFree(H1) |HandleFree(H3) |H5=HandleFromSciIpcId|
| |(id3, RO) |
| |QueryHandleParams(H5)|
| |MemMap(H5) |
| |MemUnmap(H4) |
| |MemUnmap(H5) |
| |HandleFree(H4) |
| |HandleFree(H5) |
-------------------------------------------------------------------
The race is happening between the HandleFree(H3) in process 2 and
HandleFromSciIpcId(id3, RO) in process 3. Process 2 tries to free the
H3, and function nvmap_free_handle decrements the RO dma-buf's counter,
so that it reaches 0, but nvmap_dmabuf_release is not called immediately
because of which the process 3 get's false value for the following check
if (is_ro && h->dmabuf_ro == NULL)
It results in calling nvmap_duplicate_handle and then meanwhile function
nvmap_dmabuf_release is called and it makes h->dmabuf_ro to NULL. Hence
get_dma_buf fails with null pointer dereference error.
Fix this issue with following approach:
- Before using dmabuf_ro, take the handle->lock, then check if it is not
NULL.
- If not NULL, then call get_file_rcu on the file associated with RO
dma-buf and check return value.
- If return value is false, then dma-buf's ref counter is zero and it is
going away. So wait until dmabuf_ro is set to NULL; and then create a
new dma-buf for RO.
- Otherwise, use the existing RO dma-buf and decrement the refcount
taken with get_file_rcu.
Bug 3741751
Change-Id: I8987efebc476a794b240ca968b7915b4263ba664
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2850394
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
NvMap is using bitmap_allocate_region while doing allocation from IVM
carveout. It expects size to be always power of 2, this is resulting
into memory shortage. Better way to handle this is to use the function
bitmap_find_next_zero_area which expects bitmap size rather than order.
Then use bitmap_set to set the allocated bits from the bitmap.
Similarly, while freeing the buffer, use bitmap_clear instead of
bitmap_release_region.
Bug 3923812
Change-Id: I91005d16f678405f341c4fc620509f56af538e1c
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2839848
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
get_task_struct increment the ref count over task struct, and it will be
decremented as part of put_task_struct. task_struct won't be freed
unless it's refcount becomes 0. Hence the missing put_task_struct in
nvmap code was resulting into kmemleak. Fix it by add this missing call.
Also, mutex_unlock was missing in one of the return path, add it.
Bug 3901618
Change-Id: I630eac19e628a549179a8ddaad86ad4d2c9b9a53
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2837383
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
This patch fixes the following issues:
- When the handle associated with the sub-buffer is freed, the call to
the nvmap_page_pool_fill_lots is made, which would free the pages when
the refcount on the pages is > 1, even though the main handle is not
freed, hence add a check for sub-handle.
- In cpu unmap code, list_for_each_entry is used for iterating over the
vma list and in the same loop list_del is aldo being called, this can
lead to undefined behavior, instead use list_for_each_entry_safe which
is safe against removal of list entry.
- Mutex of sub-handle is not initialized, fix it by initializing it.
- Set error value when handle creation failed.
Bug 3494980
Change-Id: I0659d7f70b44814e87e3081702352e891d9191f7
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2824668
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Some of the libraries may be linked into different namespaces, but they
belong to same process. So each namespace can open the /dev/nvmap node
and call nvmap ioctls, instead of reusing the already opened /dev/nvmap
FD. Because of this, memory handles created by one namespace can't be
used by other namespaces, even though they belong to same process.
Fix this issue by following:
- When /dev/nvmap node is opened, check if there is already any nvmap
client with same pid, if yes use that client; otherwise, create new
nvmap client.
- Track the number of namespaces via count field.
- When /dev/nvmap node is closed, destroy the nvmap client only when
count reaches to 0.
Bug 3689604
Change-Id: I4c91db36b88e78b7526dd63b006e562c8f66c7ae
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2819915
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-by: Ivan Raul Guadarrama <iguadarrama@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
On TOT, in nvmap probe function, platform_set_drvdata is called after
misc register. So nvmap node is created and clients can open it even
before platform driver data is set. Because of which, the call to
dev_get_drvdata returns NULL and BUG_ON condition is hit. Move misc
register call towards end of the nvmap probe, so that /dev/nvmap is
exposed once all initilization is completed.
As misc register being moved to end of probe, the functions which are
called before misc register and which make use of dev_user field from
nvmap_device for calling dev_err/dev_info function will see the dev
field as NULL. Hence replace such calls with pr_err/pr_info.
Bug 3853486
Change-Id: Ifdd8443812a621aceada7739cf9b02fcf00568b4
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2803672
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
On TOT, in case of carveouts, nvmap performs cache flush operation
during carveout creation, buffer allocation and buffer release. Due to
cache flush for entire carveout at creation time, nvmap takes ~430 ms
for probe. This is affecting boot KPIs.
Fix this by performing cache flush only at buffer allocation time,
instead of carveout creation and buffer release. This is reducing nvmap
probe time to ~0.69 ms.
Bug 3821631
Change-Id: I54da7dd179f8d30b8b038daf3eceafb355b2e789
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2802353
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
The resume functionality of maxim gmsl dp serializer
driver calls init routine. Function incorrectly treats
register value as return value and shows error message
in logs. Removing return value check from register read
during init fixes this issue.
bug 3955858
Change-Id: Ibe2058a49827bdd802ea4b5f24be986c911450e6
Signed-off-by: prafulls <prafulls@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2851087
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
This change adds GMSL3 support to maxim dp serializer
driver. The property is set in device tree which is if true,
then PAM4 mode is enabled and 12 Gbps link rate is set.
GMSL3 also needs to have FEC enabled. This change also
adds that support.
Device tree need to have "enable-gmsl3" property to be set
to get GMSL3 enabled.
When GMSL3 is enabled, it will enable GMSL-FEC by default.
GMSL-FEC can only be enabled by setting propery "enable-gmsl-fec".
JIRA TDS-10659
Signed-off-by: Prafull Suryawanshi <prafulls@nvidia.com>
Change-Id: I1757f71babbc5135f0ddf3d2a501de721e84da6d
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2831963
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Shu Zhong <shuz@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Upstream Linux commit ed5c2f5fd10d ("i2c: Make remove callback return
void") in Linux v6.1, updates the i2c remove callback to prototye to
return void instead of int. This is causes the Maxim DP Serialize driver
build to fail for Linux v6.1. Update this driver to fix the build for
Linux v6.1.
Bug 3820317
Bug 3835208
Change-Id: I61f4f68e67a4adf9f1744d32f7686ea962876c15
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2820718
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
This change removes worker thread from serializer driver
which waits on both links to lock. If both links are not set
via DTS entry then it does not proceed further which causes
no video output.
As it is possible that one link can be connected to deserializer,
this does not require the worker to wait on link locks. So removing
worker thread and enabling video immediately fixes this issue.
bug 3727875
Change-Id: Ie427103a7d455201a4f783d690c6250b38a9113c
Signed-off-by: Prafull Suryawanshi <prafulls@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2775207
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: Shu Zhong <shuz@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
When ruining a few hundred loops of link training between the SOC
and the serializer, we are seeing unexpected HPD_IRQ being triggered
by the MAX96745/96851 serializers due to "Branch sink count change"
event. Till we figure out why this is happening, disable this
interrupt source.
Bug 3676822
Change-Id: Id56ff7d324b9a51f5468afb2d74df7856040056d
Signed-off-by: Yogish Kulkarni <yogishk@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2758859
Reviewed-by: Shu Zhong <shuz@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
GVS: Gerrit_Virtual_Submit
This change enables external video CRC check for
Maxim DP Serializer.
This change -
1. Enable video line CRC functionality by setting specific register bit.
2. Add interrupt handler check for remote CRC check failure.
3. Reverse GPIO tunnel and remote error check is already set.
4. If there are CRC error across GMSL link then dmesg spew will indicate it.
Verification -
1. Play some GFX application and view on monitor.
2. At DES side, using GUI, For register INTR8, set bit ERR_TX_EN to 1.
3. Clear exiting dmesg using "dmesg --clear"
4. On SER, using i2ccmd tool, Set bit LINE_CRC_EN to 0 at register 0x100.
5. Confirm on dmesg for error message like - "Remote deserializer error detected"
bug 3463178
Signed-off-by: prafulls <prafulls@nvidia.com>
Change-Id: Ieba2b19b7ce1a71173f6d34e61b1607f237cb1a5
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2753202
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Shu Zhong <shuz@nvidia.com>
GVS: Gerrit_Virtual_Submit
This change enables internal video CRC check for
Maxim DP Serializer.
1. This sets the bit to enable CRC functionality
and then add handlers for ERRB CRC errors.
2. Reading register clears the error.
3. Error can be injected using i2c tool to write
error inject bit in register.
Below is flow to verify CRC functionality
1. Run GFX application like bubble
2. Read VTX41 register and confirm VID_ASIL_CRC_ERR bit is not set
3. Inject error by setting bit VID_ASIL_INJ_ERR.
4. Verify dmesg errors.
bug 3463178
Change-Id: I25c07413eb81bb4b40f35e15b53a4102ec68fa9e
Signed-off-by: prafulls <prafulls@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2751057
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Shu Zhong <shuz@nvidia.com>
GVS: Gerrit_Virtual_Submit
