1. 28 Oct, 2016 4 commits
  2. 27 Oct, 2016 9 commits
    • Andrey Vagin's avatar
      net: skip genenerating uevents for network namespaces that are exiting · 002d8a1a
      Andrey Vagin authored
      No one can see these events, because a network namespace can not be
      destroyed, if it has sockets.
      Unlike other devices, uevent-s for network devices are generated
      only inside their network namespaces. They are filtered in
      My experiments shows that net namespaces are destroyed more 30% faster
      with this optimization.
      Here is a perf output for destroying network namespaces without this
      -   94.76%     0.02%  kworker/u48:1  [kernel.kallsyms]     [k] cleanup_net
         - 94.74% cleanup_net
            - 94.64% ops_exit_list.isra.4
               - 41.61% default_device_exit_batch
                  - 41.47% unregister_netdevice_many
                     - rollback_registered_many
                        - 40.36% netdev_unregister_kobject
                           - 14.55% device_del
                              + 13.71% kobject_uevent
                           - 13.04% netdev_queue_update_kobjects
                              + 12.96% kobject_put
                           - 12.72% net_rx_queue_update_kobjects
                              - kobject_release
                                 + 12.69% kobject_uevent
                        + 0.80% call_netdevice_notifiers_info
               + 19.57% nfsd_exit_net
               + 11.15% tcp_net_metrics_exit
               + 8.25% rpcsec_gss_exit_net
      It's very critical to optimize the exit path for network namespaces,
      because they are destroyed under net_mutex and many namespaces can be
      destroyed for one iteration.
      v2: use dev_set_uevent_suppress()
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrei Vagin <avagin@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Stefan Richter's avatar
      ethernet: fix min/max MTU typos · 110447f8
      Stefan Richter authored
      Fixes: d894be57
      ('ethernet: use net core MTU range checking in more drivers')
      CC: Jarod Wilson <jarod@redhat.com>
      CC: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Acked-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
      Merge branch 'genetlink-improvements' · 0fb6af70
      David S. Miller authored
      Johannes Berg says:
      genetlink improvements
      This series contains some generic netlink improvements, making
      the API safer to use, and making the function pointers in the
      family struct safer by allowing it to be __ro_after_init.
      The first patch, introducing genl_family_attrbuf(), just ensures
      that the users of family->attrbuf aren't actually racy, but making
      them use the indirection function for obtaining a reference and
      checking that the context can actually do so.
      The second patch removes the more or less broken ability to have
      a static family ID, the three IDs that need to be static because
      it's simply needed (genl controller), or due to old API misused.
      Everything else couldn't be static anyway, or could fail when the
      family is registered, if somebody else already got a static ID.
      The third patch statically initializes the families, mostly to save
      some code. I wrote this initially because I thought I could make
      them all const, but that ends up being very inefficient (it would
      require always doing some kind of family -> id lookup), so now it's
      just here because I had it already and it reduces the code size.
      The fourth patch then, finally, lays the groundwork for what I had
      really wanted - now with __ro_after_init instead of const; I remove
      code there to do the ID->family hash table mapping in genetlink and
      use IDR instead to both allocate and map the IDs, which again ends
      up saving some code size.
      Finally, the fifth patch updates all families, as it turns out, no
      families exist that really dynamically register/unregister. This
      last patch should perhaps be split up, I could submit it for each
      subsystem separately, but it'd depend on the second and third to
      go in first, so would take a while. I can do that though, if that
      seems better to you.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Johannes Berg's avatar
      genetlink: mark families as __ro_after_init · 56989f6d
      Johannes Berg authored
      Now genl_register_family() is the only thing (other than the
      users themselves, perhaps, but I didn't find any doing that)
      writing to the family struct.
      In all families that I found, genl_register_family() is only
      called from __init functions (some indirectly, in which case
      I've add __init annotations to clarifly things), so all can
      actually be marked __ro_after_init.
      This protects the data structure from accidental corruption.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Johannes Berg's avatar
      genetlink: use idr to track families · 2ae0f17d
      Johannes Berg authored
      Since generic netlink family IDs are small integers, allocated
      densely, IDR is an ideal match for lookups. Replace the existing
      hand-written hash-table with IDR for allocation and lookup.
      This lets the families only be written to once, during register,
      since the list_head can be removed and removal of a family won't
      cause any writes.
      It also slightly reduces the code size (by about 1.3k on x86-64).
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Johannes Berg's avatar
      genetlink: statically initialize families · 489111e5
      Johannes Berg authored
      Instead of providing macros/inline functions to initialize
      the families, make all users initialize them statically and
      get rid of the macros.
      This reduces the kernel code size by about 1.6k on x86-64
      (with allyesconfig).
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Johannes Berg's avatar
      genetlink: no longer support using static family IDs · a07ea4d9
      Johannes Berg authored
      Static family IDs have never really been used, the only
      use case was the workaround I introduced for those users
      that assumed their family ID was also their multicast
      group ID.
      Additionally, because static family IDs would never be
      reserved by the generic netlink code, using a relatively
      low ID would only work for built-in families that can be
      registered immediately after generic netlink is started,
      which is basically only the control family (apart from
      the workaround code, which I also had to add code for so
      it would reserve those IDs)
      Thus, anything other than GENL_ID_GENERATE is flawed and
      luckily not used except in the cases I mentioned. Move
      those workarounds into a few lines of code, and then get
      rid of GENL_ID_GENERATE entirely, making it more robust.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Johannes Berg's avatar
      genetlink: introduce and use genl_family_attrbuf() · c90c39da
      Johannes Berg authored
      This helper function allows family implementations to access
      their family's attrbuf. This gets rid of the attrbuf usage
      in families, and also adds locking validation, since it's not
      valid to use the attrbuf with parallel_ops or outside of the
      dumpit callback.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Antonio Quartulli's avatar
      skbedit: allow the user to specify bitmask for mark · 4fe77d82
      Antonio Quartulli authored
      The user may want to use only some bits of the skb mark in
      his skbedit rules because the remaining part might be used by
      something else.
      Introduce the "mask" parameter to the skbedit actor in order
      to implement such functionality.
      When the mask is specified, only those bits selected by the
      latter are altered really changed by the actor, while the
      rest is left untouched.
      Signed-off-by: default avatarAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 26 Oct, 2016 15 commits
  4. 23 Oct, 2016 11 commits
  5. 22 Oct, 2016 1 commit