[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20200504.103204.2161530815623718852.davem@davemloft.net>
Date: Mon, 04 May 2020 10:32:04 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: tuong.t.lien@...tech.com.au
Cc: jmaloy@...hat.com, maloy@...jonn.com, ying.xue@...driver.com,
netdev@...r.kernel.org, tipc-discussion@...ts.sourceforge.net
Subject: Re: [net] tipc: fix partial topology connection closure
From: Tuong Lien <tuong.t.lien@...tech.com.au>
Date: Mon, 4 May 2020 11:15:54 +0700
> When an application connects to the TIPC topology server and subscribes
> to some services, a new connection is created along with some objects -
> 'tipc_subscription' to store related data correspondingly...
> However, there is one omission in the connection handling that when the
> connection or application is orderly shutdown (e.g. via SIGQUIT, etc.),
> the connection is not closed in kernel, the 'tipc_subscription' objects
> are not freed too.
> This results in:
> - The maximum number of subscriptions (65535) will be reached soon, new
> subscriptions will be rejected;
> - TIPC module cannot be removed (unless the objects are somehow forced
> to release first);
>
> The commit fixes the issue by closing the connection if the 'recvmsg()'
> returns '0' i.e. when the peer is shutdown gracefully. It also includes
> the other unexpected cases.
>
> Acked-by: Jon Maloy <jmaloy@...hat.com>
> Acked-by: Ying Xue <ying.xue@...driver.com>
> Signed-off-by: Tuong Lien <tuong.t.lien@...tech.com.au>
Applied, thanks.
Powered by blists - more mailing lists