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. > So please give that patch a try, let's see if we miss any other problem. Will do. I have not forgotten. I hope to have results for you in a few days. > > 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. Thanks, -K
