On Sat, Feb 18, 2017 at 4:19 AM, David Miller <davem@xxxxxxxxxxxxx> wrote:
> From: Xin Long <lucien.xin@xxxxxxxxx>
> Date: Fri, 17 Feb 2017 16:35:24 +0800
>
>
>> + list = rhltable_lookup(&sctp_transport_hashtable, &arg,
>> + sctp_hash_params);
>> +
>> + rhl_for_each_entry_rcu(transport, tmp, list, node)
>> + if (transport->asoc->ep == t->asoc->ep) {
>> + err = -EEXIST;
>> + goto out;
>> + }
>> +
>> err = rhltable_insert_key(&sctp_transport_hashtable, &arg,
>> &t->node, sctp_hash_params);
>> +
>> +out:
>
> Well, what if another thread of control inserts a matching transport
> after you've checked the list but before rhltable_insert_key() does
> it's work?
>
> What write side lock is being held to protect the table from
> modifications here?
sock lock.
...
sctp_assoc_add_peer()
sctp_hash_transport()
rhltable_insert_key()
all the places where it call sctp_assoc_add_peer() are proctected by
lock_sock(). it's a big lock, no need to worry about race issues here.
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
