* [PATCH] netfilter: nf_ct_helper: Fix possible panic when nf_conntrack_helper_unregister is used in an unloadable module
@ 2019-03-01 5:56 Su Yanjun
2019-03-01 8:43 ` Sergei Shtylyov
2019-03-08 15:59 ` Pablo Neira Ayuso
0 siblings, 2 replies; 5+ messages in thread
From: Su Yanjun @ 2019-03-01 5:56 UTC (permalink / raw)
To: pablo, kadlec, fw, davem, netfilter-devel, coreteam, netdev,
linux-kernel
Cc: suyj.fnst, suyanjun218
From: Su Yanjun <suyj.fnst@cn.fujitsu.com>
Because nf_conntrack_helper_unregister maybe used in an unloadable module,
it uses 'synchronize_rcu' which may cause kernel panic.
According to the artical:
RCU and Unloadable Modules
https://lwn.net/Articles/217484/
When we have a heavy rcu callback load, then some of the callbacks might be
deferred in order to allow other processing to proceed. sychnorize_rcu does
not wait rcu callback complete and module may be unloaded before callback
done.
This patch uses rcu_barrier instead of synchronize_rcu will prevent this
situation.
Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
---
net/netfilter/nf_conntrack_helper.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_conntrack_helper.c b/net/netfilter/nf_conntrack_helper.c
index 274baf1..0ee9378 100644
--- a/net/netfilter/nf_conntrack_helper.c
+++ b/net/netfilter/nf_conntrack_helper.c
@@ -397,8 +397,15 @@ void nf_conntrack_helper_unregister(struct nf_conntrack_helper *me)
/* Make sure every nothing is still using the helper unless its a
* connection in the hash.
+ *
+ * 'synchronize_rcu' may have problem when rcu callback function
+ * is used in unloadable modules. Use rcu_barrier instead, so that
+ * it will wait until rcu callback completes before modules are
+ * unloaded.
+ * More detail about rcu_barrier please see:
+ * https://lwn.net/Articles/217484/
*/
- synchronize_rcu();
+ rcu_barrier();
nf_ct_expect_iterate_destroy(expect_iter_me, NULL);
nf_ct_iterate_destroy(unhelp, me);
@@ -406,7 +413,7 @@ void nf_conntrack_helper_unregister(struct nf_conntrack_helper *me)
/* Maybe someone has gotten the helper already when unhelp above.
* So need to wait it.
*/
- synchronize_rcu();
+ rcu_barrier();
}
EXPORT_SYMBOL_GPL(nf_conntrack_helper_unregister);
--
2.7.4
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] netfilter: nf_ct_helper: Fix possible panic when nf_conntrack_helper_unregister is used in an unloadable module
2019-03-01 5:56 [PATCH] netfilter: nf_ct_helper: Fix possible panic when nf_conntrack_helper_unregister is used in an unloadable module Su Yanjun
@ 2019-03-01 8:43 ` Sergei Shtylyov
2019-03-01 9:08 ` Su Yanjun <suyj.fnst@cn.fujitsu.com>
2019-03-08 15:59 ` Pablo Neira Ayuso
1 sibling, 1 reply; 5+ messages in thread
From: Sergei Shtylyov @ 2019-03-01 8:43 UTC (permalink / raw)
To: Su Yanjun, pablo, kadlec, fw, davem, netfilter-devel, coreteam,
netdev, linux-kernel
Cc: suyj.fnst
Hello!
On 01.03.2019 8:56, Su Yanjun wrote:
> From: Su Yanjun <suyj.fnst@cn.fujitsu.com>
>
> Because nf_conntrack_helper_unregister maybe used in an unloadable module,
> it uses 'synchronize_rcu' which may cause kernel panic.
>
> According to the artical:
Article?
> RCU and Unloadable Modules
> https://lwn.net/Articles/217484/
>
> When we have a heavy rcu callback load, then some of the callbacks might be
> deferred in order to allow other processing to proceed. sychnorize_rcu does
> not wait rcu callback complete and module may be unloaded before callback
> done.
>
> This patch uses rcu_barrier instead of synchronize_rcu will prevent this
^ that/which missed?
> situation.
>
> Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
[...]
MBR, Sergei
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] netfilter: nf_ct_helper: Fix possible panic when nf_conntrack_helper_unregister is used in an unloadable module
2019-03-01 8:43 ` Sergei Shtylyov
@ 2019-03-01 9:08 ` Su Yanjun <suyj.fnst@cn.fujitsu.com>
0 siblings, 0 replies; 5+ messages in thread
From: Su Yanjun <suyj.fnst@cn.fujitsu.com> @ 2019-03-01 9:08 UTC (permalink / raw)
To: Sergei Shtylyov, Su Yanjun, pablo, kadlec, fw, davem,
netfilter-devel, coreteam, netdev, linux-kernel
On 2019/3/1 16:43, Sergei Shtylyov wrote:
> Hello!
>
> On 01.03.2019 8:56, Su Yanjun wrote:
>
>> From: Su Yanjun <suyj.fnst@cn.fujitsu.com>
>>
>> Because nf_conntrack_helper_unregister maybe used in an unloadable
>> module,
>> it uses 'synchronize_rcu' which may cause kernel panic.
>>
>> According to the artical:
>
> Article?
>
I got it.
>> RCU and Unloadable Modules
>> https://lwn.net/Articles/217484/
>>
>> When we have a heavy rcu callback load, then some of the callbacks
>> might be
>> deferred in order to allow other processing to proceed.
>> sychnorize_rcu does
>> not wait rcu callback complete and module may be unloaded before
>> callback
>> done.
>>
>> This patch uses rcu_barrier instead of synchronize_rcu will prevent this
> ^ that/which
> missed?
>
Yes.
>> situation.
>>
>> Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
> [...]
>
> MBR, Sergei
>
>
Thanks.
Su
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] netfilter: nf_ct_helper: Fix possible panic when nf_conntrack_helper_unregister is used in an unloadable module
2019-03-01 5:56 [PATCH] netfilter: nf_ct_helper: Fix possible panic when nf_conntrack_helper_unregister is used in an unloadable module Su Yanjun
2019-03-01 8:43 ` Sergei Shtylyov
@ 2019-03-08 15:59 ` Pablo Neira Ayuso
2019-03-14 3:20 ` Su Yanjun <suyj.fnst@cn.fujitsu.com>
1 sibling, 1 reply; 5+ messages in thread
From: Pablo Neira Ayuso @ 2019-03-08 15:59 UTC (permalink / raw)
To: Su Yanjun
Cc: kadlec, fw, davem, netfilter-devel, coreteam, netdev,
linux-kernel, suyj.fnst
On Fri, Mar 01, 2019 at 01:56:06PM +0800, Su Yanjun wrote:
> From: Su Yanjun <suyj.fnst@cn.fujitsu.com>
>
> Because nf_conntrack_helper_unregister maybe used in an unloadable module,
> it uses 'synchronize_rcu' which may cause kernel panic.
>
> According to the artical:
> RCU and Unloadable Modules
> https://lwn.net/Articles/217484/
>
> When we have a heavy rcu callback load, then some of the callbacks might be
> deferred in order to allow other processing to proceed. sychnorize_rcu does
> not wait rcu callback complete and module may be unloaded before callback
> done.
>
> This patch uses rcu_barrier instead of synchronize_rcu will prevent this
> situation.
>
> Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
> ---
> net/netfilter/nf_conntrack_helper.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/nf_conntrack_helper.c b/net/netfilter/nf_conntrack_helper.c
> index 274baf1..0ee9378 100644
> --- a/net/netfilter/nf_conntrack_helper.c
> +++ b/net/netfilter/nf_conntrack_helper.c
> @@ -397,8 +397,15 @@ void nf_conntrack_helper_unregister(struct nf_conntrack_helper *me)
>
> /* Make sure every nothing is still using the helper unless its a
> * connection in the hash.
> + *
> + * 'synchronize_rcu' may have problem when rcu callback function
> + * is used in unloadable modules. Use rcu_barrier instead, so that
> + * it will wait until rcu callback completes before modules are
> + * unloaded.
> + * More detail about rcu_barrier please see:
> + * https://lwn.net/Articles/217484/
> */
> - synchronize_rcu();
> + rcu_barrier();
Are you sure this is correct?
IIRC rcu_barrier() makes sure no pending callback is still waiting in
the queue to run. We have don't use call_rcu() in this code, which is
what rcu_barrier() is meant for.
Please correct me if I'm mistaken.
Thanks!
>
> nf_ct_expect_iterate_destroy(expect_iter_me, NULL);
> nf_ct_iterate_destroy(unhelp, me);
> @@ -406,7 +413,7 @@ void nf_conntrack_helper_unregister(struct nf_conntrack_helper *me)
> /* Maybe someone has gotten the helper already when unhelp above.
> * So need to wait it.
> */
> - synchronize_rcu();
> + rcu_barrier();
> }
> EXPORT_SYMBOL_GPL(nf_conntrack_helper_unregister);
>
> --
> 2.7.4
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] netfilter: nf_ct_helper: Fix possible panic when nf_conntrack_helper_unregister is used in an unloadable module
2019-03-08 15:59 ` Pablo Neira Ayuso
@ 2019-03-14 3:20 ` Su Yanjun <suyj.fnst@cn.fujitsu.com>
0 siblings, 0 replies; 5+ messages in thread
From: Su Yanjun <suyj.fnst@cn.fujitsu.com> @ 2019-03-14 3:20 UTC (permalink / raw)
To: Pablo Neira Ayuso, Su Yanjun
Cc: kadlec, fw, davem, netfilter-devel, coreteam, netdev, linux-kernel
On 2019/3/8 23:59, Pablo Neira Ayuso wrote:
> On Fri, Mar 01, 2019 at 01:56:06PM +0800, Su Yanjun wrote:
>> From: Su Yanjun<suyj.fnst@cn.fujitsu.com>
>>
>> Because nf_conntrack_helper_unregister maybe used in an unloadable module,
>> it uses 'synchronize_rcu' which may cause kernel panic.
>>
>> According to the artical:
>> RCU and Unloadable Modules
>> https://lwn.net/Articles/217484/
>>
>> When we have a heavy rcu callback load, then some of the callbacks might be
>> deferred in order to allow other processing to proceed. sychnorize_rcu does
>> not wait rcu callback complete and module may be unloaded before callback
>> done.
>>
>> This patch uses rcu_barrier instead of synchronize_rcu will prevent this
>> situation.
>>
>> Signed-off-by: Su Yanjun<suyj.fnst@cn.fujitsu.com>
>> ---
>> net/netfilter/nf_conntrack_helper.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/netfilter/nf_conntrack_helper.c b/net/netfilter/nf_conntrack_helper.c
>> index 274baf1..0ee9378 100644
>> --- a/net/netfilter/nf_conntrack_helper.c
>> +++ b/net/netfilter/nf_conntrack_helper.c
>> @@ -397,8 +397,15 @@ void nf_conntrack_helper_unregister(struct nf_conntrack_helper *me)
>>
>> /* Make sure every nothing is still using the helper unless its a
>> * connection in the hash.
>> + *
>> + * 'synchronize_rcu' may have problem when rcu callback function
>> + * is used in unloadable modules. Use rcu_barrier instead, so that
>> + * it will wait until rcu callback completes before modules are
>> + * unloaded.
>> + * More detail about rcu_barrier please see:
>> + *https://lwn.net/Articles/217484/
>> */
>> - synchronize_rcu();
>> + rcu_barrier();
> Are you sure this is correct?
>
> IIRC rcu_barrier() makes sure no pending callback is still waiting in
> the queue to run. We have don't use call_rcu() in this code, which is
> what rcu_barrier() is meant for.
>
> Please correct me if I'm mistaken.
>
> Thanks!
The issue is not whether your module invokes|call_rcu()|,
but rather whether the corresponding RCU callback invokes a function that is in a module.
For unloadable modules, **rcu_barrier** make the code more robust than synchronize_rcu.
Thanks
Su
>>
>> nf_ct_expect_iterate_destroy(expect_iter_me, NULL);
>> nf_ct_iterate_destroy(unhelp, me);
>> @@ -406,7 +413,7 @@ void nf_conntrack_helper_unregister(struct nf_conntrack_helper *me)
>> /* Maybe someone has gotten the helper already when unhelp above.
>> * So need to wait it.
>> */
>> - synchronize_rcu();
>> + rcu_barrier();
>> }
>> EXPORT_SYMBOL_GPL(nf_conntrack_helper_unregister);
>>
>> --
>> 2.7.4
>>
>>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-03-14 3:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-01 5:56 [PATCH] netfilter: nf_ct_helper: Fix possible panic when nf_conntrack_helper_unregister is used in an unloadable module Su Yanjun
2019-03-01 8:43 ` Sergei Shtylyov
2019-03-01 9:08 ` Su Yanjun <suyj.fnst@cn.fujitsu.com>
2019-03-08 15:59 ` Pablo Neira Ayuso
2019-03-14 3:20 ` Su Yanjun <suyj.fnst@cn.fujitsu.com>
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).