[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081205195624.95ea1866.akpm@linux-foundation.org>
Date: Fri, 5 Dec 2008 19:56:24 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: "m m" <olsajiri@...il.com>
Cc: linux-kernel@...r.kernel.org, linux-net@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: netlink - notify when the socket gets closed
(cc netdev@...r.kernel.org)
On Fri, 5 Dec 2008 09:17:51 +0100 "m m" <olsajiri@...il.com> wrote:
> Hi,
>
> I'm using netlink in my module. Based on the communication,
> this module dynamically creates some internal structure, which
> needs to be destroyed when the user level socket is closed (or
> the application dies).
>
> I found I could use the netlink_register_notifier function to register
> NETLINK_URELEASE callback during the netlink_release function.
> But since my module uses the multicast netlink socket communication,
> it wont be called:
>
> static int netlink_release(struct socket *sock)
> {
> ...
>
> if (nlk->pid && !nlk->subscriptions) {
> struct netlink_notify n = {
> .net = sock_net(sk),
> .protocol = sk->sk_protocol,
> .pid = nlk->pid,
> };
> atomic_notifier_call_chain(&netlink_chain,
> NETLINK_URELEASE, &n);
> }
> ...
>
> Whats the reason this callback is not called for multicast sockets?
>
> To workaround it I created simple misc device which the user application
> opens before creating the netlink socket. This way I get some callbacks
> inside the module when the application dies, at least.. pretty ugly :)
>
> Is there a netlink mechanism to be notified when the netlink socket is
> closed on the user level side? (when using multicast communication)
>
> Or is there any other design I could use, since I think I'm not alone in
> using internal module data which needs to be removed once the application dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists