1. 28 4月, 2008 1 次提交
  2. 19 4月, 2008 1 次提交
  3. 26 3月, 2008 3 次提交
  4. 22 3月, 2008 1 次提交
  5. 01 3月, 2008 2 次提交
  6. 02 2月, 2008 1 次提交
  7. 01 2月, 2008 1 次提交
    • P
      [NETNS]: Fix race between put_net() and netlink_kernel_create(). · 23fe1866
      Pavel Emelyanov 提交于
      The comment about "race free view of the set of network
      namespaces" was a bit hasty. Look (there even can be only
      one CPU, as discovered by Alexey Dobriyan and Denis Lunev):
      
      put_net()
        if (atomic_dec_and_test(&net->refcnt))
          /* true */
            __put_net(net);
              queue_work(...);
      
      /*
       * note: the net now has refcnt 0, but still in
       * the global list of net namespaces
       */
      
      == re-schedule ==
      
      register_pernet_subsys(&some_ops);
        register_pernet_operations(&some_ops);
          (*some_ops)->init(net);
            /*
             * we call netlink_kernel_create() here
             * in some places
             */
            netlink_kernel_create();
               sk_alloc();
                  get_net(net); /* refcnt = 1 */
               /*
                * now we drop the net refcount not to
                * block the net namespace exit in the
                * future (or this can be done on the
                * error path)
                */
               put_net(sk->sk_net);
                   if (atomic_dec_and_test(&...))
                         /*
                          * true. BOOOM! The net is
                          * scheduled for release twice
                          */
      
      When thinking on this problem, I decided, that getting and
      putting the net in init callback is wrong. If some init
      callback needs to have a refcount-less reference on the struct
      net, _it_ has to be careful himself, rather than relying on
      the infrastructure to handle this correctly.
      
      In case of netlink_kernel_create(), the problem is that the
      sk_alloc() gets the given namespace, but passing the info
      that we don't want to get it inside this call is too heavy.
      
      Instead, I propose to crate the socket inside an init_net
      namespace and then re-attach it to the desired one right
      after the socket is created.
      
      After doing this, we also have to be careful on error paths
      not to drop the reference on the namespace, we didn't get
      the one on.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Acked-by: NDenis Lunev <den@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      23fe1866
  8. 29 1月, 2008 8 次提交
  9. 13 11月, 2007 1 次提交
  10. 07 11月, 2007 1 次提交
  11. 01 11月, 2007 1 次提交
  12. 27 10月, 2007 1 次提交
    • E
      [NET]: Marking struct pernet_operations __net_initdata was inappropriate · 2b008b0a
      Eric W. Biederman 提交于
      It is not safe to to place struct pernet_operations in a special section.
      We need struct pernet_operations to last until we call unregister_pernet_subsys.
      Which doesn't happen until module unload.
      
      So marking struct pernet_operations is a disaster for modules in two ways.
      - We discard it before we call the exit method it points to.
      - Because I keep struct pernet_operations on a linked list discarding
        it for compiled in code removes elements in the middle of a linked
        list and does horrible things for linked insert.
      
      So this looks safe assuming __exit_refok is not discarded
      for modules.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2b008b0a
  13. 24 10月, 2007 1 次提交
  14. 16 10月, 2007 1 次提交
  15. 11 10月, 2007 13 次提交
  16. 19 7月, 2007 2 次提交
  17. 18 7月, 2007 1 次提交