[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1e17123-0b69-291b-db04-ccc8e1be1c97@windriver.com>
Date: Wed, 5 Sep 2018 11:19:36 +0800
From: Ying Xue <ying.xue@...driver.com>
To: Cong Wang <xiyou.wangcong@...il.com>, <netdev@...r.kernel.org>
CC: <tipc-discussion@...ts.sourceforge.net>,
Jon Maloy <jon.maloy@...csson.com>
Subject: Re: [Patch net v3] tipc: call start and done ops directly in
__tipc_nl_compat_dumpit()
On 09/05/2018 05:54 AM, Cong Wang wrote:
> __tipc_nl_compat_dumpit() uses a netlink_callback on stack,
> so the only way to align it with other ->dumpit() call path
> is calling tipc_dump_start() and tipc_dump_done() directly
> inside it. Otherwise ->dumpit() would always get NULL from
> cb->args[].
>
> But tipc_dump_start() uses sock_net(cb->skb->sk) to retrieve
> net pointer, the cb->skb here doesn't set skb->sk, the net pointer
> is saved in msg->net instead, so introduce a helper function
> __tipc_dump_start() to pass in msg->net.
>
> Ying pointed out cb->args[0...3] are already used by other
> callbacks on this call path, so we can't use cb->args[0] any
> more, use cb->args[4] instead.
It's a common mechanism to save rhashtable iterator pointer in cb->args
after tipc_dump_start() and tipc_dump_done() are introduced. Someday
probably we will involve new dumpit function. In order to lower the risk
that rhashtable iterator pointer saved is overwritten, it's better to
use the last slot, ie, cb->args[5].
Powered by blists - more mailing lists