Searched hist:363151 (Results 1 - 18 of 18) sorted by relevance
| /freebsd-11-stable/sys/dev/mlx5/mlx5_fpga_tools/ | ||
| H A D | mlx5fpga_tools_main.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| /freebsd-11-stable/sys/ofed/drivers/infiniband/util/ | ||
| H A D | madeye.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| /freebsd-11-stable/sys/dev/mlx4/mlx4_en/ | ||
| H A D | mlx4_en_main.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| /freebsd-11-stable/sys/dev/mlx4/mlx4_core/ | ||
| H A D | mlx4_main.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| /freebsd-11-stable/sys/ofed/drivers/infiniband/core/ | ||
| H A D | ib_ucm.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| H A D | ib_device.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| H A D | ib_iwcm.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| H A D | ib_uverbs_main.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| H A D | ib_user_mad.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| H A D | ib_cm.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| H A D | ib_ucma.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| H A D | ib_cma.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| /freebsd-11-stable/sys/dev/mthca/ | ||
| H A D | mthca_main.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| /freebsd-11-stable/sys/dev/mlx4/mlx4_ib/ | ||
| H A D | mlx4_ib_main.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| /freebsd-11-stable/sys/dev/mlx5/mlx5_ib/ | ||
| H A D | mlx5_ib_main.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| /freebsd-11-stable/sys/ofed/drivers/infiniband/ulp/ipoib/ | ||
| H A D | ipoib_main.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| /freebsd-11-stable/sys/dev/mlx5/mlx5_core/ | ||
| H A D | mlx5_main.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
| /freebsd-11-stable/sys/dev/mlx5/mlx5_en/ | ||
| H A D | mlx5_en_main.c | diff 363151 Mon Jul 13 15:38:10 MDT 2020 hselasky MFC r362953: Infiniband clients must be attached and detached in a specific order in ibcore. Currently the linking order of the infiniband, IB, modules decide in which order the clients are attached and detached. For example one IB client may use resources from another IB client. This can lead to a potential deadlock at shutdown. For example if the ipoib is unregistered after the ib_multicast client is detached, then if ipoib is using multicast addresses a deadlock may happen, because ib_multicast will wait for all its resources to be freed before returning from the remove method. Fix this by using module_xxx_order() instead of module_xxx(). Differential Revision: https://reviews.freebsd.org/D23973 Sponsored by: Mellanox Technologies |
Completed in 211 milliseconds