Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37 |
|
#
1bae5c0e |
| 29-Jun-2023 |
Chengfeng Ye <dg573847474@gmail.com> |
misc: bcm_vk: Fix potential deadlock on &vk->ctx_lock
As &vk->ctx_lock is acquired by timer bcm_vk_hb_poll() under softirq context, other process context code should disable irq or bottom-half befor
misc: bcm_vk: Fix potential deadlock on &vk->ctx_lock
As &vk->ctx_lock is acquired by timer bcm_vk_hb_poll() under softirq context, other process context code should disable irq or bottom-half before acquire the same lock, otherwise deadlock could happen if the timer preempt the execution while the lock is held in process context on the same CPU.
Possible deadlock scenario bcm_vk_open() -> bcm_vk_get_ctx() -> spin_lock(&vk->ctx_lock) <timer iterrupt> -> bcm_vk_hb_poll() -> bcm_vk_blk_drv_access() -> spin_lock_irqsave(&vk->ctx_lock, flags) (deadlock here)
This flaw was found using an experimental static analysis tool we are developing for irq-related deadlock, which reported the following warning when analyzing the linux kernel 6.4-rc7 release.
[Deadlock]: &vk->ctx_lock [Interrupt]: bcm_vk_hb_poll -->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:176 -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512 [Locking Unit]: bcm_vk_ioctl -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:1181 -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512
[Deadlock]: &vk->ctx_lock [Interrupt]: bcm_vk_hb_poll -->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:176 -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512 [Locking Unit]: bcm_vk_ioctl -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:1169
[Deadlock]: &vk->ctx_lock [Interrupt]: bcm_vk_hb_poll -->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:176 -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512 [Locking Unit]: bcm_vk_open -->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:216
[Deadlock]: &vk->ctx_lock [Interrupt]: bcm_vk_hb_poll -->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:176 -->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512 [Locking Unit]: bcm_vk_release -->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:306
As suggested by Arnd, the tentative patch fix the potential deadlocks by replacing the timer with delay workqueue. x86_64 allyesconfig using GCC shows no new warning. Note that no runtime testing was performed due to no device on hand.
Signed-off-by: Chengfeng Ye <dg573847474@gmail.com> Acked-by: Scott Branden <scott.branden@broadcom.com> Tested-by: Desmond Yan <desmond.branden@broadcom.com> Tested-by: Desmond Yan <desmond.yan@broadcom.com> Link: https://lore.kernel.org/r/20230629182941.13045-1-dg573847474@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32 |
|
#
88517757 |
| 27-Mar-2022 |
Jakob Koschel <jakobkoschel@gmail.com> |
misc: bcm-vk: replace usage of found with dedicated list iterator variable
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the lis
misc: bcm-vk: replace usage of found with dedicated list iterator variable
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 <jakobkoschel@gmail.com> Link: https://lore.kernel.org/r/20220327214551.2188544-1-jakobkoschel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43 |
|
#
20827ddd |
| 09-Jun-2021 |
Baokun Li <libaokun1@huawei.com> |
misc: bcm-vk: use list_move_tail instead of list_del/list_add_tail in bcm_vk_msg.c
Using list_move_tail() instead of list_del() + list_add_tail() in bcm_vk_msg.c.
Reported-by: Hulk Robot <hulkci@hu
misc: bcm-vk: use list_move_tail instead of list_del/list_add_tail in bcm_vk_msg.c
Using list_move_tail() instead of list_del() + list_add_tail() in bcm_vk_msg.c.
Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Baokun Li <libaokun1@huawei.com> Link: https://lore.kernel.org/r/20210609071430.1337400-1-libaokun1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10.42, v5.10.41, v5.10.40, v5.10.39 |
|
#
208012f0 |
| 14-May-2021 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
misc: bcm-vk: Replace zero-length array with flexible array member
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structur
misc: bcm-vk: Replace zero-length array with flexible array member
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2].
Also, make use of the struct_size() helper in kzalloc().
[1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays
Acked-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20210514230801.GA35863@embeddedor Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
d7a4bfca |
| 01-Feb-2021 |
Dan Carpenter <dan.carpenter@oracle.com> |
misc: bcm-vk: unlock on error in bcm_to_h_msg_dequeue()
Unlock before returning on this error path.
Fixes: 111d746bb476 ("misc: bcm-vk: add VK messaging support") Acked-by: Desmond Yan <desmond.yan
misc: bcm-vk: unlock on error in bcm_to_h_msg_dequeue()
Unlock before returning on this error path.
Fixes: 111d746bb476 ("misc: bcm-vk: add VK messaging support") Acked-by: Desmond Yan <desmond.yan@broadcom.com> Acked-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YBfyb+jU5lDUe+5g@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
d71277dc |
| 29-Jan-2021 |
Desmond Yan <desmond.yan@broadcom.com> |
misc: bcm-vk: fix set_q_num API precedence issue
Change set_q_num API to use if-else to make it more explicit, and avoid a precedence rule issue.
Reported-by: kernel test robot <lkp@intel.com> Sign
misc: bcm-vk: fix set_q_num API precedence issue
Change set_q_num API to use if-else to make it more explicit, and avoid a precedence rule issue.
Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Desmond Yan <desmond.yan@broadcom.com> Signed-off-by: Scott Branden <scott.branden@broadcom.com> Link: https://lore.kernel.org/r/20210129060403.14801-1-scott.branden@broadcom.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
d63d658f |
| 20-Jan-2021 |
Scott Branden <scott.branden@broadcom.com> |
misc: bcm-vk: reset_pid support
Add reset support via ioctl. Kill user processes that are open when VK card is reset. If a particular PID has issued the reset request do not kill that process as it
misc: bcm-vk: reset_pid support
Add reset support via ioctl. Kill user processes that are open when VK card is reset. If a particular PID has issued the reset request do not kill that process as it issued the ioctl.
Co-developed-by: Desmond Yan <desmond.yan@broadcom.com> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Desmond Yan <desmond.yan@broadcom.com> Signed-off-by: Scott Branden <scott.branden@broadcom.com> Link: https://lore.kernel.org/r/20210120175827.14820-11-scott.branden@broadcom.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
111d746b |
| 20-Jan-2021 |
Scott Branden <scott.branden@broadcom.com> |
misc: bcm-vk: add VK messaging support
Add message support in order to be able to communicate to VK card via message queues.
This info is used for debug purposes via collection of logs via direct r
misc: bcm-vk: add VK messaging support
Add message support in order to be able to communicate to VK card via message queues.
This info is used for debug purposes via collection of logs via direct read of BAR space and by sysfs access (in a follow on commit).
Co-developed-by: Desmond Yan <desmond.yan@broadcom.com> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Desmond Yan <desmond.yan@broadcom.com> Signed-off-by: Scott Branden <scott.branden@broadcom.com> Link: https://lore.kernel.org/r/20210120175827.14820-10-scott.branden@broadcom.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
22c30607 |
| 20-Jan-2021 |
Scott Branden <scott.branden@broadcom.com> |
misc: bcm-vk: add open/release
Add open/release to replace private data with context for other methods to use. Reason for the context is because it is allowed for multiple sessions to open sysfs.
misc: bcm-vk: add open/release
Add open/release to replace private data with context for other methods to use. Reason for the context is because it is allowed for multiple sessions to open sysfs. For each file open, when upper layer queries the response, only those that are tied to a specified open should be returned.
Co-developed-by: Desmond Yan <desmond.yan@broadcom.com> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Desmond Yan <desmond.yan@broadcom.com> Signed-off-by: Scott Branden <scott.branden@broadcom.com> Link: https://lore.kernel.org/r/20210120175827.14820-7-scott.branden@broadcom.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|