On Tue, Oct 11, 2016 at 2:28 AM, Krister Johansen <k...@templeofstupid.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!
