1. 20 2月, 2009 1 次提交
    • P
      netlink: add NETLINK_BROADCAST_ERROR socket option · be0c22a4
      Pablo Neira Ayuso 提交于
      This patch adds NETLINK_BROADCAST_ERROR which is a netlink
      socket option that the listener can set to make netlink_broadcast()
      return errors in the delivery to the caller. This option is useful
      if the caller of netlink_broadcast() do something with the result
      of the message delivery, like in ctnetlink where it drops a network
      packet if the event delivery failed, this is used to enable reliable
      logging and state-synchronization. If this socket option is not set,
      netlink_broadcast() only reports ESRCH errors and silently ignore
      ENOBUFS errors, which is what most netlink_broadcast() callers
      should do.
      
      This socket option is based on a suggestion from Patrick McHardy.
      Patrick McHardy can exchange this patch for a beer from me ;).
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Acked-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be0c22a4
  2. 06 2月, 2009 1 次提交
    • P
      netlink: change return-value logic of netlink_broadcast() · ff491a73
      Pablo Neira Ayuso 提交于
      Currently, netlink_broadcast() reports errors to the caller if no
      messages at all were delivered:
      
      1) If, at least, one message has been delivered correctly, returns 0.
      2) Otherwise, if no messages at all were delivered due to skb_clone()
         failure, return -ENOBUFS.
      3) Otherwise, if there are no listeners, return -ESRCH.
      
      With this patch, the caller knows if the delivery of any of the
      messages to the listeners have failed:
      
      1) If it fails to deliver any message (for whatever reason), return
         -ENOBUFS.
      2) Otherwise, if all messages were delivered OK, returns 0.
      3) Otherwise, if no listeners, return -ESRCH.
      
      In the current ctnetlink code and in Netfilter in general, we can add
      reliable logging and connection tracking event delivery by dropping the
      packets whose events were not successfully delivered over Netlink. Of
      course, this option would be settable via /proc as this approach reduces
      performance (in terms of filtered connections per seconds by a stateful
      firewall) but providing reliable logging and event delivery (for
      conntrackd) in return.
      
      This patch also changes some clients of netlink_broadcast() that
      may report ENOBUFS errors via printk. This error handling is not
      of any help. Instead, the userspace daemons that are listening to
      those netlink messages should resync themselves with the kernel-side
      if they hit ENOBUFS.
      
      BTW, netlink_broadcast() clients include those that call
      cn_netlink_send(), nlmsg_multicast() and genlmsg_multicast() since they
      internally call netlink_broadcast() and return its error value.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff491a73
  3. 25 11月, 2008 1 次提交
  4. 24 11月, 2008 2 次提交
  5. 17 10月, 2008 1 次提交
  6. 14 10月, 2008 1 次提交
  7. 26 7月, 2008 1 次提交
  8. 02 7月, 2008 1 次提交
  9. 06 6月, 2008 1 次提交
  10. 28 4月, 2008 1 次提交
  11. 19 4月, 2008 1 次提交
  12. 26 3月, 2008 3 次提交
  13. 22 3月, 2008 1 次提交
  14. 01 3月, 2008 2 次提交
  15. 02 2月, 2008 1 次提交
  16. 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
  17. 29 1月, 2008 8 次提交
  18. 13 11月, 2007 1 次提交
  19. 07 11月, 2007 1 次提交
  20. 01 11月, 2007 1 次提交
  21. 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
  22. 24 10月, 2007 1 次提交
  23. 16 10月, 2007 1 次提交
  24. 11 10月, 2007 6 次提交