Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1572068
| From | Cong Wang <xiyou.wangcong@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: net: suspicious RCU usage in nf_hook |
| Date | 2017-02-02 00:40 +0100 |
| Message-ID | <t6cFk-4kV-19@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <t4q9H-3hQ-5@gated-at.bofh.it> <t5A70-5JM-19@gated-at.bofh.it> <t5IQW-2qi-15@gated-at.bofh.it> <t6aau-2uM-23@gated-at.bofh.it> <t6atP-2Vw-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
On Wed, Feb 1, 2017 at 1:16 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2017-02-01 at 12:51 -0800, Cong Wang wrote:
>> On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote:
>> >
>> >>
>> >> The context is process context (TX path before hitting qdisc), and
>> >> BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this
>> >> makes me thinking maybe we really need to disable BH in this
>> >> case for nf_hook()? But it is called in RX path too, and BH is
>> >> already disabled there.
>> >
>> > ipt_do_table() and similar netfilter entry points disable BH.
>> >
>> > Maybe it is done too late.
>>
>> I think we need a fix like the following one for minimum impact.
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 727b6fd..eee7d63 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -1720,12 +1720,10 @@ EXPORT_SYMBOL(net_enable_timestamp);
>> void net_disable_timestamp(void)
>> {
>> #ifdef HAVE_JUMP_LABEL
>> - if (in_interrupt()) {
>> - atomic_inc(&netstamp_needed_deferred);
>> - return;
>> - }
>> -#endif
>> + atomic_inc(&netstamp_needed_deferred);
>> +#else
>> static_key_slow_dec(&netstamp_needed);
>> +#endif
>> }
>> EXPORT_SYMBOL(net_disable_timestamp);
>
> This would permanently leave the kernel in the netstamp_needed state.
>
> I would prefer the patch using a process context to perform the
> cleanup ? Note there is a race window, but probably not a big deal.
Not sure if it is better. The difference is caught up in net_enable_timestamp(),
which is called setsockopt() path and sk_clone() path, so we could be
in netstamp_needed state for a long time too until user-space exercises
these paths.
I am feeling we probably need to get rid of netstamp_needed_deferred,
and simply defer the whole static_key_slow_dec(), like the attached patch
(compile only).
What do you think?
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: net: suspicious RCU usage in nf_hook Cong Wang <xiyou.wangcong@gmail.com> - 2017-01-31 07:30 +0100
Re: net: suspicious RCU usage in nf_hook Eric Dumazet <eric.dumazet@gmail.com> - 2017-01-31 16:50 +0100
Re: net: suspicious RCU usage in nf_hook Cong Wang <xiyou.wangcong@gmail.com> - 2017-02-01 22:00 +0100
Re: net: suspicious RCU usage in nf_hook Eric Dumazet <eric.dumazet@gmail.com> - 2017-02-01 22:20 +0100
Re: net: suspicious RCU usage in nf_hook Eric Dumazet <eric.dumazet@gmail.com> - 2017-02-01 22:30 +0100
Re: net: suspicious RCU usage in nf_hook Cong Wang <xiyou.wangcong@gmail.com> - 2017-02-02 00:40 +0100
Re: net: suspicious RCU usage in nf_hook Eric Dumazet <edumazet@google.com> - 2017-02-02 00:50 +0100
Re: net: suspicious RCU usage in nf_hook Eric Dumazet <eric.dumazet@gmail.com> - 2017-02-02 01:00 +0100
Re: net: suspicious RCU usage in nf_hook Cong Wang <xiyou.wangcong@gmail.com> - 2017-02-02 19:10 +0100
csiph-web