From: Vlad Y. <vla...@hp...> - 2007-02-27 21:29:49
|
Hi Neil Neil Horman wrote: > Hey all- > I'm currently tracking down a potential association reference count > leak, and in my searching I ran accross something that troubled me (which may or > may not be related to the problem I am currently diagnosing). > > It involves the endpoint strucutres list of associations. Specifically, > I see two problems: > > 1) I see no lock protecting that list. I see in sctp_endpoint_lookup_assoc we > do a sctp_local_bh_disable which would protect us from modifications that occur > during local receive operations, but not from receive operations that happen on > other cpu's hmm... I don't think this is strictly necessary. Things that add an association to the endpoint's list: 1) sctp_assoc_migrate(). Done when the socket lock for both source and destination socket is held. 2) sctp_cmd_interpreter(). Done when the socket spin-lock is held. Things that delete an association from the endpoint's list: 1) sctp_association_free(). This is called froma 9 different places: sctp_make_temp_asoc() - not an issue since temporary associations do not get linked to the endpoint. (check if this is your issue). sctp_unpack_cookie() - in the fail case, we never link the association to the endpoint. sctp_cmd_delete_tcb() - since this is part of the command interpreter, we are holding the socket spin lock. No-one else should have access to the endpoint. sctp_sf_do_5_1B_init() - failure case, never link. holding socket lock anyway. sctp_sf_do_5_1D_ce() - failure case, never linkg. holding socket lock. sctp_sf_do_unexpected_init() - same __sctp_connect() - we are under the the sctp_lock_sock(). sctp_close() - we are under sctp_lock_sock(). sctp_sendmsg() - we are under sctp_lock_sock(). Hmm... looks like a there might be a bug in sctp_shutdown()!!! We generate traffic and change the association contents without holding a lock!!! > > 2) I see no method for removing items from the endpoint->asocs list. I imagine > this could be particularly problematic as associations refcounts reached zero, > since it appears that all associations are allocated in sctp_association_new > (which sets malloced to 1), but in sctp_association_destroy we just call kfree > if malloced is one, instead of sctp_association_free, which appears responsible > for deleting the association from the endpoint->assocs list. The result is bad > entries on the asocs list. Actually, sctp_association_free() removes the item from the assocs list. It does: list_del(&asoc->asocs); which unlinkes the assoc from the list. Can you describe the scenario a bit. Later -vlad |