[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180723105915.a6vx5t7htcclez3k@breakpoint.cc>
Date: Mon, 23 Jul 2018 12:59:15 +0200
From: Florian Westphal <fw@...len.de>
To: shaochun chen <cscnull@...il.com>
Cc: Florian Westphal <fw@...len.de>,
Pablo Neira Ayuso <pablo@...filter.org>,
David Miller <davem@...emloft.net>,
kadlec <kadlec@...ckhole.kfki.hu>,
"johannes.berg" <johannes.berg@...el.com>, jason <Jason@...c4.com>,
ktkhai <ktkhai@...tuozzo.com>,
"lucien.xin" <lucien.xin@...il.com>,
"xiyou.wangcong" <xiyou.wangcong@...il.com>,
dsahern <dsahern@...il.com>,
netfilter-devel <netfilter-devel@...r.kernel.org>,
tom <tom@...ntonium.net>, netdev <netdev@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] netlink: fix memory leak of dump
shaochun chen <cscnull@...il.com> wrote:
> I have a question: we will try_module_get in __netlink_dump_start(),
Thats too late, we release rcu read lock before this, so the module
implementing ->dump might have been removed already.
> but why we need to call try_module_get again in nft_netlink_dump_start ??
Its the other way around.
This is the first try_module_get; at this point we still hold rcu read
lock.
If nf_tables module is being removed, try_module_get will fail and
we can error out.
If it succeeds, its safe to drop the rcu read lock.
Powered by blists - more mailing lists