• T
    tipc: fix memory leak in service subscripting · c77a9ea9
    Tuong Lien 提交于
    stable inclusion
    from linux-4.19.149
    commit 6b3ea3aa6c675b65b6b068f5726c93abc8a4b460
    
    --------------------------------
    
    [ Upstream commit 0771d7df ]
    
    Upon receipt of a service subscription request from user via a topology
    connection, one 'sub' object will be allocated in kernel, so it will be
    able to send an event of the service if any to the user correspondingly
    then. Also, in case of any failure, the connection will be shutdown and
    all the pertaining 'sub' objects will be freed.
    
    However, there is a race condition as follows resulting in memory leak:
    
           receive-work       connection        send-work
                  |                |                |
            sub-1 |<------//-------|                |
            sub-2 |<------//-------|                |
                  |                |<---------------| evt for sub-x
            sub-3 |<------//-------|                |
                  :                :                :
                  :                :                :
                  |       /--------|                |
                  |       |        * peer closed    |
                  |       |        |                |
                  |       |        |<-------X-------| evt for sub-y
                  |       |        |<===============|
            sub-n |<------/        X    shutdown    |
        -> orphan |                                 |
    
    That is, the 'receive-work' may get the last subscription request while
    the 'send-work' is shutting down the connection due to peer close.
    
    We had a 'lock' on the connection, so the two actions cannot be carried
    out simultaneously. If the last subscription is allocated e.g. 'sub-n',
    before the 'send-work' closes the connection, there will be no issue at
    all, the 'sub' objects will be freed. In contrast the last subscription
    will become orphan since the connection was closed, and we released all
    references.
    
    This commit fixes the issue by simply adding one test if the connection
    remains in 'connected' state right after we obtain the connection lock,
    then a subscription object can be created as usual, otherwise we ignore
    it.
    Acked-by: NYing Xue <ying.xue@windriver.com>
    Acked-by: NJon Maloy <jmaloy@redhat.com>
    Reported-by: NThang Ngo <thang.h.ngo@dektech.com.au>
    Signed-off-by: NTuong Lien <tuong.t.lien@dektech.com.au>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    Signed-off-by: NSasha Levin <sashal@kernel.org>
    Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: NAichun Li <liaichun@huawei.com>
    Reviewed-by: Nwangxiaopeng <wangxiaopeng7@huawei.com>
    Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
    c77a9ea9
topsrv.c 18.7 KB