1. 20 3月, 2009 1 次提交
  2. 25 2月, 2009 1 次提交
    • P
      netlink: change nlmsg_notify() return value logic · 1ce85fe4
      Pablo Neira Ayuso 提交于
      This patch changes the return value of nlmsg_notify() as follows:
      
      If NETLINK_BROADCAST_ERROR is set by any of the listeners and
      an error in the delivery happened, return the broadcast error;
      else if there are no listeners apart from the socket that
      requested a change with the echo flag, return the result of the
      unicast notification. Thus, with this patch, the unicast
      notification is handled in the same way of a broadcast listener
      that has set the NETLINK_BROADCAST_ERROR socket flag.
      
      This patch is useful in case that the caller of nlmsg_notify()
      wants to know the result of the delivery of a netlink notification
      (including the broadcast delivery) and take any action in case
      that the delivery failed. For example, ctnetlink can drop packets
      if the event delivery failed to provide reliable logging and
      state-synchronization at the cost of dropping packets.
      
      This patch also modifies the rtnetlink code to ignore the return
      value of rtnl_notify() in all callers. The function rtnl_notify()
      (before this patch) returned the error of the unicast notification
      which makes rtnl_set_sk_err() reports errors to all listeners. This
      is not of any help since the origin of the change (the socket that
      requested the echoing) notices the ENOBUFS error if the notification
      fails and should resync itself.
      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>
      1ce85fe4
  3. 31 1月, 2009 1 次提交
  4. 21 11月, 2008 1 次提交
  5. 23 9月, 2008 1 次提交
  6. 26 7月, 2008 1 次提交
  7. 20 7月, 2008 1 次提交
  8. 11 6月, 2008 1 次提交
  9. 04 6月, 2008 1 次提交
  10. 24 4月, 2008 1 次提交
    • P
      [RTNETLINK]: Fix bogus ASSERT_RTNL warning · c9c1014b
      Patrick McHardy 提交于
      ASSERT_RTNL uses mutex_trylock to test whether the rtnl_mutex is
      held. This bogus warnings when running in atomic context, which
      f.e. happens when adding secondary unicast addresses through
      macvlan or vlan or when synchronizing multicast addresses from
      wireless devices.
      
      Mid-term we might want to consider moving all address updates
      to process context since the locking seems overly complicated,
      for now just fix the bogus warning by changing ASSERT_RTNL to
      use mutex_is_locked().
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9c1014b
  11. 05 2月, 2008 1 次提交
  12. 29 1月, 2008 2 次提交
  13. 13 11月, 2007 1 次提交
  14. 11 10月, 2007 1 次提交
    • P
      [IPv6]: Export userland ND options through netlink (RDNSS support) · 31910575
      Pierre Ynard 提交于
      As discussed before, this patch provides userland with a way to access
      relevant options in Router Advertisements, after they are processed
      and validated by the kernel. Extra options are processed in a generic
      way; this patch only exports RDNSS options described in RFC5006, but
      support to control which options are exported could be easily added.
      
      A new rtnetlink message type is defined, to transport Neighbor
      Discovery options, along with optional context information. At the
      moment only the address of the router sending an RDNSS option is
      included, but additional attributes may be later defined, if needed by
      new use cases.
      Signed-off-by: NPierre Ynard <linkfanel@yahoo.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31910575
  15. 31 8月, 2007 1 次提交
  16. 11 7月, 2007 3 次提交
  17. 26 4月, 2007 2 次提交
  18. 09 12月, 2006 1 次提交
  19. 03 12月, 2006 2 次提交
  20. 29 9月, 2006 1 次提交
  21. 23 9月, 2006 11 次提交
  22. 26 4月, 2006 1 次提交
  23. 23 3月, 2006 1 次提交
  24. 21 3月, 2006 2 次提交