1. 18 Feb, 2016 1 commit
  2. 15 Dec, 2015 1 commit
  3. 24 Sep, 2015 1 commit
  4. 12 Mar, 2015 1 commit
    • Eric W. Biederman's avatar
      net: Introduce possible_net_t · 0c5c9fb5
      Eric W. Biederman authored
      Having to say
      > #ifdef CONFIG_NET_NS
      > 	struct net *net;
      > #endif
      
      in structures is a little bit wordy and a little bit error prone.
      
      Instead it is possible to say:
      > typedef struct {
      > #ifdef CONFIG_NET_NS
      >       struct net *net;
      > #endif
      > } possible_net_t;
      
      And then in a header say:
      
      > 	possible_net_t net;
      
      Which is cleaner and easier to use and easier to test, as the
      possible_net_t is always there no matter what the compile options.
      
      Further this allows read_pnet and write_pnet to be functions in all
      cases which is better at catching typos.
      
      This change adds possible_net_t, updates the definitions of read_pnet
      and write_pnet, updates optional struct net * variables that
      write_pnet uses on to have the type possible_net_t, and finally fixes
      up the b0rked users of read_pnet and write_pnet.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c5c9fb5
  5. 26 Jan, 2015 1 commit
  6. 17 Jan, 2015 1 commit
    • Johannes Berg's avatar
      netlink: make nlmsg_end() and genlmsg_end() void · 053c095a
      Johannes Berg authored
      Contrary to common expectations for an "int" return, these functions
      return only a positive value -- if used correctly they cannot even
      return 0 because the message header will necessarily be in the skb.
      
      This makes the very common pattern of
      
        if (genlmsg_end(...) < 0) { ... }
      
      be a whole bunch of dead code. Many places also simply do
      
        return nlmsg_end(...);
      
      and the caller is expected to deal with it.
      
      This also commonly (at least for me) causes errors, because it is very
      common to write
      
        if (my_function(...))
          /* error condition */
      
      and if my_function() does "return nlmsg_end()" this is of course wrong.
      
      Additionally, there's not a single place in the kernel that actually
      needs the message length returned, and if anyone needs it later then
      it'll be very easy to just use skb->len there.
      
      Remove this, and make the functions void. This removes a bunch of dead
      code as described above. The patch adds lines because I did
      
      -	return nlmsg_end(...);
      +	nlmsg_end(...);
      +	return 0;
      
      I could have preserved all the function's return values by returning
      skb->len, but instead I've audited all the places calling the affected
      functions and found that none cared. A few places actually compared
      the return value with <= 0 in dump functionality, but that could just
      be changed to < 0 with no change in behaviour, so I opted for the more
      efficient version.
      
      One instance of the error I've made numerous times now is also present
      in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
      check for <0 or <=0 and thus broke out of the loop every single time.
      I've preserved this since it will (I think) have caused the messages to
      userspace to be formatted differently with just a single message for
      every SKB returned to userspace. It's possible that this isn't needed
      for the tools that actually use this, but I don't even know what they
      are so couldn't test that changing this behaviour would be acceptable.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      053c095a
  7. 16 Jan, 2015 2 commits
    • Johannes Berg's avatar
      genetlink: synchronize socket closing and family removal · ee1c2442
      Johannes Berg authored
      In addition to the problem Jeff Layton reported, I looked at the code
      and reproduced the same warning by subscribing and removing the genl
      family with a socket still open. This is a fairly tricky race which
      originates in the fact that generic netlink allows the family to go
      away while sockets are still open - unlike regular netlink which has
      a module refcount for every open socket so in general this cannot be
      triggered.
      
      Trying to resolve this issue by the obvious locking isn't possible as
      it will result in deadlocks between unregistration and group unbind
      notification (which incidentally lockdep doesn't find due to the home
      grown locking in the netlink table.)
      
      To really resolve this, introduce a "closing socket" reference counter
      (for generic netlink only, as it's the only affected family) in the
      core netlink code and use that in generic netlink to wait for all the
      sockets that are being closed at the same time as a generic netlink
      family is removed.
      
      This fixes the race that when a socket is closed, it will should call
      the unbind, but if the family is removed at the same time the unbind
      will not find it, leading to the warning. The real problem though is
      that in this case the unbind could actually find a new family that is
      registered to have a multicast group with the same ID, and call its
      mcast_unbind() leading to confusing.
      
      Also remove the warning since it would still trigger, but is now no
      longer a problem.
      
      This also moves the code in af_netlink.c to before unreferencing the
      module to avoid having the same problem in the normal non-genl case.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee1c2442
    • Johannes Berg's avatar
      genetlink: document parallel_ops · f555f3d7
      Johannes Berg authored
      The kernel-doc for the parallel_ops family struct member is
      missing, add it.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f555f3d7
  8. 27 Dec, 2014 3 commits
  9. 19 Sep, 2014 1 commit
  10. 06 Jan, 2014 1 commit
  11. 21 Nov, 2013 2 commits
  12. 19 Nov, 2013 6 commits
  13. 15 Nov, 2013 1 commit
  14. 14 Nov, 2013 4 commits
  15. 20 Sep, 2013 1 commit
  16. 28 Aug, 2013 1 commit
  17. 24 Apr, 2013 1 commit
    • Pravin B Shelar's avatar
      genl: Allow concurrent genl callbacks. · def31174
      Pravin B Shelar authored
      All genl callbacks are serialized by genl-mutex. This can become
      bottleneck in multi threaded case.
      Following patch adds an parameter to genl_family so that a
      particular family can get concurrent netlink callback without
      genl_lock held.
      New rw-sem is used to protect genl callback from genl family unregister.
      in case of parallel_ops genl-family read-lock is taken for callbacks and
      write lock is taken for register or unregistration for any family.
      In case of locked genl family semaphore and gel-mutex is locked for
      any openration.
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      def31174
  18. 10 Sep, 2012 1 commit
  19. 28 Jun, 2012 1 commit
    • Thomas Graf's avatar
      net: Use NLMSG_DEFAULT_SIZE in combination with nlmsg_new() · 58050fce
      Thomas Graf authored
      Using NLMSG_GOODSIZE results in multiple pages being used as
      nlmsg_new() will automatically add the size of the netlink
      header to the payload thus exceeding the page limit.
      
      NLMSG_DEFAULT_SIZE takes this into account.
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Cc: Jiri Pirko <jpirko@redhat.com>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: Sergey Lapin <slapin@ossfans.org>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Lauro Ramos Venancio <lauro.venancio@openbossa.org>
      Cc: Aloisio Almeida Jr <aloisio.almeida@openbossa.org>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Reviewed-by: default avatarJiri Pirko <jpirko@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58050fce
  20. 30 Jan, 2012 1 commit
  21. 03 Dec, 2011 1 commit
  22. 22 Jun, 2011 1 commit
    • Johannes Berg's avatar
      netlink: advertise incomplete dumps · 670dc283
      Johannes Berg authored
      Consider the following situation:
       * a dump that would show 8 entries, four in the first
         round, and four in the second
       * between the first and second rounds, 6 entries are
         removed
       * now the second round will not show any entry, and
         even if there is a sequence/generation counter the
         application will not know
      
      To solve this problem, add a new flag NLM_F_DUMP_INTR
      to the netlink header that indicates the dump wasn't
      consistent, this flag can also be set on the MSG_DONE
      message that terminates the dump, and as such above
      situation can be detected.
      
      To achieve this, add a sequence counter to the netlink
      callback struct. Of course, netlink code still needs
      to use this new functionality. The correct way to do
      that is to always set cb->seq when a dumpit callback
      is invoked and call nl_dump_check_consistent() for
      each new message. The core code will also call this
      function for the final MSG_DONE message.
      
      To make it usable with generic netlink, a new function
      genlmsg_nlhdr() is needed to obtain the netlink header
      from the genetlink user header.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      670dc283
  23. 10 May, 2011 1 commit
  24. 03 Feb, 2011 1 commit
  25. 05 Oct, 2010 1 commit
    • Johannes Berg's avatar
      genetlink: introduce pre_doit/post_doit hooks · ff4c92d8
      Johannes Berg authored
      Each family may have some amount of boilerplate
      locking code that applies to most, or even all,
      commands.
      
      This allows a family to handle such things in
      a more generic way, by allowing it to
       a) include private flags in each operation
       b) specify a pre_doit hook that is called,
          before an operation's doit() callback and
          may return an error directly,
       c) specify a post_doit hook that can undo
          locking or similar things done by pre_doit,
          and finally
       d) include two private pointers in each info
          struct passed between all these operations
          including doit(). (It's two because I'll
          need two in nl80211 -- can be extended.)
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ff4c92d8
  26. 02 Jun, 2010 1 commit
  27. 04 Nov, 2009 1 commit
  28. 12 Jul, 2009 1 commit
    • Johannes Berg's avatar
      genetlink: make netns aware · 134e6375
      Johannes Berg authored
      This makes generic netlink network namespace aware. No
      generic netlink families except for the controller family
      are made namespace aware, they need to be checked one by
      one and then set the family->netnsok member to true.
      
      A new function genlmsg_multicast_netns() is introduced to
      allow sending a multicast message in a given namespace,
      for example when it applies to an object that lives in
      that namespace, a new function genlmsg_multicast_allns()
      to send a message to all network namespaces (for objects
      that do not have an associated netns).
      
      The function genlmsg_multicast() is changed to multicast
      the message in just init_net, which is currently correct
      for all generic netlink families since they only work in
      init_net right now. Some will later want to work in all
      net namespaces because they do not care about the netns
      at all -- those will have to be converted to use one of
      the new functions genlmsg_multicast_allns() or
      genlmsg_multicast_netns() whenever they are made netns
      aware in some way.
      
      After this patch families can easily decide whether or
      not they should be available in all net namespaces. Many
      genl families us it for objects not related to networking
      and should therefore be available in all namespaces, but
      that will have to be done on a per family basis.
      
      Note that this doesn't touch on the checkpoint/restart
      problem where network namespaces could be used, genl
      families and multicast groups are numbered globally and
      I see no easy way of changing that, especially since it
      must be possible to multicast to all network namespaces
      for those families that do not care about netns.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      134e6375