[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAM_iQpUitQOD4v03zAC48HhXBRodVyx5htU3W1yd3+N3hc9yZg@mail.gmail.com>
Date: Tue, 11 Oct 2016 10:51:04 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Krister Johansen <kjlx@...pleofstupid.com>
Cc: Jamal Hadi Salim <jhs@...atatu.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH net] Panic when tc_lookup_action_n finds a partially
initialized action.
On Tue, Oct 11, 2016 at 2:28 AM, Krister Johansen
<kjlx@...pleofstupid.com> wrote:
> On Wed, Oct 05, 2016 at 11:01:38AM -0700, Cong Wang wrote:
>> Does the attached patch make any sense now? Our pernet init doesn't
>> rely on act_base, so even we have some race, the worst case is after
>> we initialize the pernet netns for an action but its ops still not
>> visible, which seems fine (at least no crash).
>
> I tried to reproduce the panic with this latest patch, but I am unable
> to do so. The one difference I notice between this patch, and the one I
Nice, so the crash is fixed. I will send out my patch formally.
> sent to the list, is that with yours it takes much longer before we get
> any output from the simultaneous launch of these containers. Presumably
> that's the extra latency added by allowing many extra modprobe calls to
> get spawned by request_module().
This is a different problem. When we register a pernet ops, the ops->init()
will be called on each container to initialize its pernet data structures,
this is why request_module() blocks on waiting for register_pernet_subsys()
to finish. As we discussed earlier, this could be solved or workaround by
loading modules prior to creating containers. Or if this really needs to be
fixed, it should be in register_pernet_subsys(), since it is not specific to
tc actions, we have so many places loading modules at run-time in
networking subsystem.
Thanks for testing!
Powered by blists - more mailing lists