On Mon, 2020-06-29 at 20:18 +, stran...@codeaurora.org wrote:
>
> Thanks Cong. Yes, removing the genl_bind()/genl_unbind() functions
> eliminates the
> potential for this deadlock. Adding Johannes here to comment on removing
> these,
> as the family->mcast_bind() capability added by commit c38
On 2020-06-27 12:55, Cong Wang wrote:
On Fri, Jun 26, 2020 at 5:32 PM Sean Tranchetti
wrote:
A potential deadlock can occur during registering or unregistering a
new
generic netlink family between the main nl_table_lock and the cb_lock
where
each thread wants the lock held by the other, as
From: Sean Tranchetti
Date: Fri, 26 Jun 2020 18:31:03 -0600
> @@ -328,6 +325,10 @@ int genl_register_family(struct genl_family *family)
> if (err)
> return err;
>
> + /* Acquire netlink table lock before any GENL-specific locks to ensure
> + * sync with any netlink
On Fri, Jun 26, 2020 at 5:32 PM Sean Tranchetti wrote:
>
> A potential deadlock can occur during registering or unregistering a new
> generic netlink family between the main nl_table_lock and the cb_lock where
> each thread wants the lock held by the other, as demonstrated below.
>
> 1) Thread 1 i
A potential deadlock can occur during registering or unregistering a new
generic netlink family between the main nl_table_lock and the cb_lock where
each thread wants the lock held by the other, as demonstrated below.
1) Thread 1 is performing a netlink_bind() operation on a socket. As part
of
