Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 6
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 25 11月, 2008 1 次提交
  3. 24 11月, 2008 2 次提交
  5. 17 10月, 2008 1 次提交
  7. 14 10月, 2008 1 次提交
  9. 26 7月, 2008 1 次提交
  11. 02 7月, 2008 1 次提交
  13. 06 6月, 2008 1 次提交
  15. 28 4月, 2008 1 次提交
  17. 19 4月, 2008 1 次提交
  19. 26 3月, 2008 3 次提交
  21. 22 3月, 2008 1 次提交
  23. 01 3月, 2008 2 次提交
  25. 02 2月, 2008 1 次提交
  27. 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
  29. 29 1月, 2008 8 次提交
  31. 13 11月, 2007 1 次提交
  33. 07 11月, 2007 1 次提交
  35. 01 11月, 2007 1 次提交
  37. 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
  39. 24 10月, 2007 1 次提交
  41. 16 10月, 2007 1 次提交
  43. 11 10月, 2007 8 次提交