On Sat, Oct 8, 2016 at 11:13 PM, Krister Johansen <k...@templeofstupid.com> wrote: > Hi Cong, > Thanks for the follow-up. > > On Thu, Oct 06, 2016 at 12:01:15PM -0700, Cong Wang wrote: >> On Wed, Oct 5, 2016 at 11:11 PM, Krister Johansen >> > pernet_operations pointer. The code in register_pernet_subsys() makes >> > no attempt to check for duplicates. If we add a pointer that's already >> > in the list, and subsequently call unregister, the results seem >> > undefined. It looks like we'll remove the pernet_operations for the >> > existing action, assuming we don't corrupt the list in the process. >> > >> > Is this actually safe? If so, what corner case is the act->type / >> > act->kind protecting us from? >> >> ops->type and ops->kind should be unique too, user-space already >> relies on this (tc action ls action xxx). The code exists probably just >> for sanity check. > > With that in mind, would it make sense to change the check to a WARN/BUG > or some kind of assertion? I mistakenly inferred that it was possible to > legtimately end up in this scenario.
Yes, it makes sense to me. >> > Part of the desire to inhibit extra modprobe calls is that if hundreds >> > of these all start at once on boot, it's really unnecessary to have all >> > of the rest of them wait while lots of extra modprobe calls are forked >> > by the kernel. >> >> You can tell systemd to load these modules before starting these >> containers to avoid blocking, no? > > That was exactly what I did to work around the panic until I was able to > get a patch together. The preload of the modules is still occurring, > but I was hoping to excise that workaround entirely. Or you can compile these modules into kernel, but I am not sure about the dependencies. :-D Thanks.
